Translation UX feedback


Please leave your feedback about the new translation editor and group selector on this page. Full designs are available and the full visual specification is available on Wikimedia Commons., but not all described feature have been (or will be) implemented. Thank you for articulating it!

You can also report a bug or feature request at Phabricator.

First pagePrevious pageNext pageLast page

Incorrect number of results reported


Screenshot of new translation page as of today with contradictive messages.

We are shown "one result found after filtering" (in the yellow box) even if there are no results, as the new translation page shows just below that yellow box: "There is nothing to be translated", see attached screenshot,

Purodha Blissenbach (talk)20:50, 30 March 2013

It works for me in Dutch and English. I'll look into the "ksh" translation potentially being faulty, or otherwise the plural handling in JavaScript.

Siebrand08:36, 1 April 2013

The problem is indeed in the translation:

{{PLURAL:$1|Eine|$1|keine}} Träffer för „$2“

Should be:

{{PLURAL:$1|keine|Eine|$1}} Träffer för „$2“

Reason for this is the order of the definitions for plural forms in languages/data/plurals.xml:

        <pluralRules locales="ksh">
            <pluralRule count="zero">n is 0</pluralRule>
            <pluralRule count="one">n is 1</pluralRule>
Siebrand08:49, 1 April 2013

In MediaWiki, the order of parameters of PLURAL for ksh is:

{{PLURAL:$n | $n is one | $n is not zero and not one | $n is zero }}

for historical reasons. Since we can hardly tell MediaWiki processed message from JavaScript processed messages, having incompatible parameter orders is quite undesirable.

In additon to the historical reasons and several hundreds of message using it already, the paramter order as of MediaWiki is the better choice for leaving parameters out. The (n=zero) case is more often identical to ((n != one) and (n != zero)), but (n=one) is hardly ever identical to ((n != one) and (n != zero)).

Conclusion: I suggest to alter languages/data/plurals.xml - would the following be correct? There is some guesswork in it from my side:

        <pluralRules locales="ksh">
            <pluralRule count="one">n is 1</pluralRule>
            <pluralRule count="nonzero">n is not 0</pluralRule>
Purodha Blissenbach (talk)00:04, 4 April 2013

The above quoted data is from CLDR. We will not override it.

Siebrand00:08, 4 April 2013

Does that mean, I should change it at CLDR? That is of course possible, but will take ages until we have it here. When I submitted ksh plural definitons to CLDR, they did not have any documentation or hints on the fact that the order of cases was relevant, or even useable/used elsewhere.

As far as I know, the feature that values can be left out from the right, which TWN even enforces since not too long, is not part of the plural handling of CLDR, or at least was not, when the ksh plural rules were submitted.

Other translation platforms using the CLDR plural definitions, let translators choose the order in which they specify cases.

Does the JavaScript implementation of PLURAL support the keyword version of parameters? If so, using keywords might be a good temporary fix until a general solution is found and working,

Purodha Blissenbach (talk)00:26, 4 April 2013

This thread is created nearly 4 years ago, and is this issue fixed in the past years? If not, would asking at Phabricator be a good idea?

Liuxinyu970226 (talk)13:01, 14 May 2017

Color code altered despite unaltered editing selection.

Edited by another user.
Last edit: 11:54, 14 March 2015

In the AJAX editor, when a message class is selected, say "untranslated", editing of a message has begun but the message was neither saved nor left, and then another message class is selected, say "all", a warning message is shown via an alert subwindow, and the user is asked to either "stay on the page" or not. Before choosing to stay, the selected yet unconfirmed message class is color coded as if it was already selected. That remains so, even if the user chooses to stay with the previous selection.

Even worse - although the selection is remained, the user is from now on alterted when klicking the current but not color coded selection.

I assume, the order of performing the steps in switching / retaining / color coding / noting / keeping the current selection needs to be different from now.

Purodha Blissenbach (talk)11:51, 14 March 2015
Edited by 0 users.
Last edit: 15:42, 20 May 2017

This should be confirmed as an issue, and reported in Phabricator.

Siebrand15:42, 20 May 2017

Editing messages using the AJAX tool - using a klick point in the lower left edge.

When selecting a piece of text in the edit field first, then klicking on one of the labels in the lower left edge of the edit field, such as [$1] or [GENDER:$2], the selected text is not replaced. When typing on the keyboard, it is. That is somewhat counter-intuitive.

Purodha Blissenbach (talk)20:49, 4 March 2015

Reported as phab:T114101

Glaisher (talk)17:36, 8 August 2016

AJAX editing hides error message when edits were not saved.

About 5 to 7 percent of the times when I hit the "save translation" link or button in the AJAX editor, saving fails, and a newly added error message is shown in the page. But at the same time, the page is scrolled up a bit to a position where the error message is just outside the visible area (viewport). As a result, I never know about the error unless at the end of a session, I scroll through the entire page so as to control, if all went well. Since that often takes very long, and since Mozilla and other browsers usually crash after a while due to the memory leaks (which I assume are part of JavaScript libraries), I often loose a part of the edits made with AJAX editing.

Ideas of remedies:

  • Do not scroll the dynamic status/error message to become invisible.
    • Scroll back to failing message when an error is detected.
  • Give an audible feedback (similar to cash registers in supermarkets) of success/failure.
    • Given an audible feedback only on failure.
    • Let users select audio files to be played, including none, for both cases.
  • Alter something sufficiently visible when an error is detected, such as overall background color, etc.
Purodha Blissenbach (talk)08:38, 25 May 2015

I also think there's room for improvement here so I have reported it as phab:T142411.

Glaisher (talk)17:21, 8 August 2016

Message group "Recent additions"

There is an aggregate message group "Recent additions" which is pretty handy for me with one drawback. It lists messages belonging to projects that I do not translate. While that occasionally makes me translate one or another of those, which of course does not hurt, it creates quite some clutter in the AJAX editor. It there a way to avoid that?

Purodha Blissenbach (talk)06:06, 10 June 2015

Filtering by group is not currently possible.

Nike (talk)06:09, 10 June 2015

See Thread:Support/Recent_additions_message_group for two more precisely described drawbacks.

Purodha Blissenbach (talk)17:37, 18 June 2016

Recent additions message group

While the message group of the recent additions is really helpful and I use it a lot, it has two disadvantages to me:

  1. It encompasses message of projects for which I do not want to or cannot translate
    • A general message group filter per user may solve that.
  2. It mixes messages from various contexts that message documentations assume some knowledge of, which makes it very confusing and at times almost impossible to find appropriate precise translations.
    • A link to the message group of each message might help with that, which can imho decently be put in the pulldown list at the beginning of the edit boxes of the messages.


Purodha Blissenbach (talk)10:27, 17 March 2016

Main page project list - low priority.

Logged in users are offered a series of project for which they are asked to translate. This may include ones which are already 100% translated and this is shown. It might be wise to offer only project for which there is something to do, a courtesy to the users. :-)

Purodha Blissenbach (talk)18:02, 8 December 2015

Feedback on the process for new translators

I invited Blockly users to sign up with translatewiki and got this feedback from an experienced developer, which I thought would be useful to your usability team:

Thank you for starting this. Translating and incorporating new translations should be much more scalable now, yay! I was excited to translate the puzzle... but after an hour, I still can't do that yet.
So I think some heads-up to translators who are unacquainted with translatewiki will probably be very helpful. Can you please provide more instruction on how to get started? As a completely new user, here are the issues I ran into. (Warning: I'll be going into details :)
- When I first went to "", I had no clue that the first link "Translate this project" at the very top was it. I finished reading the page, looked over the puzzle app for some link to download a file... you know, like the old way. I even poked at the en.json file and almost got going with it... :)
- Next, I didn't know I had to request permission to start translating. I did realize I needed to create an account and did that. Then, after I went back to Blockly project and clicked "Translate this project", and selected Vietnamese, and started to edit the messages/phrases... there was no "Save" button anywhere. Only then did I find the note about permission, and went to request it.
- Requesting permission takes a while (it's not a matter of minutes, as I'm still waiting for my approval after almost an hour). In order to request permission, we have to go through the "Getting started wizard", which confused me a bit, too, especially around "Configure your preferences" and which language was which. I was like "I just wanted to start translating Blockly!"
These are just issues about getting acquainted to wikitranslate. I'm not sure if we have any capacity to help improve wikitranslate itself, so it's just helpful to give some heads-up to enthusiastic Blockly translators.
Espertus (talk)17:39, 29 April 2013

Thank you. I think this is being worked on, in the meanwhile the easiest thing to do is usually to send people to the main page or Special:FirstSteps directly; after they do that, finding the translation interface is easy, while the contrary is less.

Nemo (talk)18:18, 29 April 2013

Thanks for the gracious and helpful reply.

Espertus (talk)18:49, 29 April 2013

To answer a question from chat, my statement above was not sarcastic.

Neither is this one.  :-)

Espertus (talk)23:50, 29 April 2013

Where is next page button??

I'm on and can't find the next page button... Talk about display all. I clicked every thing clickable (that's a nice word...) but to no use. How do you get to the next page? This really isn't a user-friendly update of the UI.

Nedergard (talk)10:12, 23 September 2015

No such feature exists. Scroll to the bottom of the page and more messages will be loaded, if available.

Nemo (talk)16:58, 23 September 2015

in the function 'Editing documentation' no suggestions are displayed

When trying to create Wikimedia:Wikiedudashboard-courses.students short/qqq there were no suggestions made by the system. I would have expected to get among the suggestions from the sytem {{Identical|Student}}. This used to be the case on the old server.

Robby (talk)22:32, 23 July 2015

Functionality is being removed from action=edit etc., see Project:News.

Nemo (talk)22:55, 23 July 2015

That's a pity it was quite useful to me.

Robby (talk)18:23, 27 July 2015

Click points overlapping text in edit field

Screenshot showing click points that overlap the text the editing subwindow in the AJAX editor in twn.

Click points can overlap with text in the editing subwindow in the AJAX editor. See attached screen shot.

Purodha Blissenbach (talk)07:37, 19 June 2015

Click points spilling out of edit field

Screenshot showing click points spilling out of the editing subwindow in the AJAX editor in twn

Click points can spill out of the lower edge of the editing subwindow in the AJAX editor. See attached screen shot.

Purodha Blissenbach (talk)07:17, 19 June 2015

Changes to AJAX translation pages

There was a layout and color change on the AJAX translation pages having two drawbacks:

  1. Blue texts on blue background are (next to) unreadable on many devices.
  2. Normal checking of the "optional to translate" checkbox became impossible.
Purodha Blissenbach (talk)16:25, 14 May 2015

Are you talking of the mw:MediaWiki UI style?

Nemo (talk)17:55, 14 May 2015

I am talking about what I get. I do not know what style that is named.

My skin setting is "Vector" since the moment, twn management without choice compelled us to that.

Purodha Blissenbach (talk)20:59, 14 May 2015

Monobook was re-enabled several months ago.

To determine whether what you are seeing is MediaWiki UI, you can compare to the screenshot I linked (the inspect tool of your browser may also help): generally it's distinguished by the fatness of objects, abundance of whitespace and mild/pastel colours.

Nemo (talk)07:29, 15 May 2015

Which screenshot? Your answer is very cryptic to me.

I do have a little personal .css but the only color related statement there is:

.diffchange-inline { color:black }

which cannot be responsible for blue texts on blue backgrounds.

Purodha Blissenbach (talk)08:05, 15 May 2015

I tried Monobook and got the same blue-on-blue-mess and the same half-heigt-background-colour-split lines as before.

Purodha Blissenbach (talk)08:17, 15 May 2015

Normal edit page are now partially next to unreadable, since many lines of text are now half and half on different background colors. Having to select them in the browser in order to make them readable is just a drag. :-(

Purodha Blissenbach (talk)08:02, 15 May 2015

Missing clicking point in AJAX editor.

Screenshot showing a message with a $5 parameter in the AJAX editing window. It is rendered without a clicking point for $5 while clicking points exist for all other parameters.

See attached screenshot showing a message with a $5 parameter in the AJAX editing window. It is rendered without a clicking point for $5 while clicking points exist for all other parameters. That is inconsistent.

Purodha Blissenbach (talk)08:29, 14 March 2015

Link to edit support translations and translation memory.

When editing with the new AJAX based tool, if we find typing errors in a suggestion coming from the translation memory, or in one of the support translations to other languages, getting to an edit page with the intent to correct them is very complicated and time consuming and by the way needlessly consumes a lot of network traffic and server processing time. An "edit in separate tab/window" link per message would imho be a better solution.

Purodha Blissenbach (talk)04:54, 12 March 2015

Translations to Wuu language in Wikimedia Mobile Apps group should be disabled.

A thread, Thread:Support/Translations to wuu language in Wikimedia Mobile Apps group should be disabled., was moved from here to Support/LiquidThreads. This move was made by Nemo bis (talk | contribs) on 15 November 2014 at 07:25.

Problems with outdated messages

When working on updating the outdated messages sometimes the button "This translation may need to be updated. Show differences" is not shown (it should be located just above the text area box).

Instead of showing the difference (like here) I have seen two other types of texts:

  1. "This translation may need to be updated." (Example)
  2. A message showing a problem, such as "Following parameter is not used: %number%" (note that this is still an outdated message). (Example, updated by FuzzyBot).

Does anyone have any idea why?

Jopparn (talk)13:22, 25 September 2014

This is bugzilla:48187. It was WONTFIX'ed, because it should go away in some years anyway.

Nemo (talk)10:21, 13 November 2014

Special:ManageTranslatorSandbox: Sending reminder emails seems to not working correctly

When I click on the link "Send email reminder" and I call up the page later, there is no hint anymore about previous email deliveries. Please have a look.

\m/etalhead 09:22, 12 July 2014

Is this still current?

Nemo (talk)09:11, 18 September 2014


On the new main page, in the 4 blue boxes with the main statistics for the site, the number appears above the words. In Swahili, a number comes after the thing counted, not before. Is it possible to swap the order so that the words can appear above the numbers?

Lloffiwr (talk)14:12, 18 May 2013

Not currently.

Nike (talk)15:22, 18 May 2013

What about the future?

Nemo (talk)19:47, 16 September 2014

Upcoming changes in registration process

Edited by 2 users.
Last edit: 10:16, 15 December 2013

We are planning to enable the new main page for all users soon[*]. Currently it is only shown for logged in users. With the main page a new registration process comes. There will be a form on the main page for signing up. After that users will be directed to Special:TranslationStash where they can make translation that will not be visible outside that page. Admins (those who currently can assign "translator" right) will need to use the Special:ManageTranslatorSandbox page to approve translators.

The old process with Special:FirstSteps and Project:Translator will be deprecated and removed once we are confident with the new process.

More information:

Please help translating the new pages:

[*] as soon as we have fixed the last remaining blockers in the functionality

Nike (talk)10:12, 13 December 2013
Edited by author.
Last edit: 20:40, 23 December 2013

I see email addresses in Special:ManageTranslatorSandbox. Is the user who registers warned of such exposure?

Project:Privacy policy only mentions email addresses to say that they're not normally shown and says «the access [...] should be minimal and should be used only internally to serve the well-being of the project [...] Registered users are not required to provide an email address». Systematically looking at the email address of registered users is not "minimal" access, so unless/until there is a warning in the registration phase or in the privacy policy the current interface is illegal in EU where this website is hosted and operated. All this IANAL of course; please check.

P.s.: I've added to my special:mypage/common.css:

.email {
        display: none;

.reminder-email {
        display: none;

to avoid seeing information I may not be legally authorised to see.

Nemo (talk)15:16, 19 December 2013

I'll add the hiding to mediawiki:common.css as stopgap solution until the problem is addressed, if there are no objections.

Nemo (talk)20:41, 23 December 2013

I don't understand the interface when the requester also has made some translations, which is one case out of nine currently in Special:ManageTranslatorSandbox and specifically a translator to Hebrew.

  • The first column is clear, it's the source text.
  • The second column has a translation and a subtext with the language name: I can tell because it's the same string shown at top or I'd have no idea what עברית is.
  • The third column contains "existing translations", with a message key as subtext.
    • In one of them, it seems to be the existing text of the message in the subtext, which (in the source language) is identical to another untranslated message, so the latter is probably what's being translated (but I have no way to know).
    • In another, the same, but there are no other messages with that English text so the translated message must be the same. Will the new translation overwrite the old if I accept the translator, or if not what will happen of it?
    • In the other two cases, the third column contains nothing but the subtext.
Nemo (talk)22:26, 23 December 2013

metalhead, are you able to answer the questions above? I still have no idea how this undocumented feature works.

Nemo (talk)08:33, 10 March 2014

I'm still interested in answers to my questions. In the meanwhile I'm trying to collect what's known about the feature in FAQ#How_do_I_register.3F.

Nemo (talk)21:01, 9 September 2014

The old process is established, but I'm wondering what should be the criteria to review incoming requests. In my opinion, we should accept translators if we have an amount of positive information similar to what we used to have from FirstSteps (or higher), and not reject requests unless we have (strong) hints that an account is a vandal.

Most requests currently don't contain any information or translation, but that's not something to blame users for. It's possible that they registered now and will only add translations later (after filling the form they're immediately told "You're now a translator"), so empty/non-actionable requests should IMHO be left alone at least for some weeks or months.

Nemo (talk)09:28, 24 December 2013

As yet, I rejected requests that were older than 48 hours and no test translations were made.

\m/etalhead 17:35, 26 December 2013

Thanks for sharing, \m/etalhead. For your information, rejection implies delivering of this message (I've not checked the code but there isn't any other): MediaWiki:Tsb-email-rejected-body/en. The message:

  • is very negative ("rejected [...] quality [...] did not meet the requirements [...] rejected"),
  • implies that applying again may sometimes be impossible ("try to apply again"; might be a typo for "try and", though, and translators may have translated it in friendlier/different ways).
Nemo (talk)12:10, 7 January 2014
Nemo (talk)11:39, 6 March 2014

The instructions to developers ("If you are a developer interested in documenting translations, or just exploring the platform, you are also welcome".)who want to add documentation is to join as an ordinary user, not a translator. But I thought that they needed translator rights to add documentation to qqq. So are they being given translator rights by some other review process?

And how about the translators who are trying to sign up to translate into a language which hasn't been enabled yet? If they can't use the sandbox they might give up if there isn't a link to the list of enabled languages and instructions on what to do if their language isn't on the list.

Lloffiwr (talk)17:00, 9 March 2014
First pagePrevious pageNext pageLast page