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.

OPEN This issue is open, waiting for action

Update:

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,

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.

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>
        </pluralRules>

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>
        </pluralRules>

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

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,

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?

OPEN This issue is open, waiting for action

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.

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

CLOSED This issue is closed by glaisher

Still true as of June 2016. Tracked.

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.

Reported as phab:T114101

CLOSED This issue is closed by glaisher

TUX devs don't seem willing to change design that way. tracked

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.

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

OPEN This issue is open, waiting for action

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?

Filtering by group is not currently possible.

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

CLOSED This issue is closed

Duplicate of Thread:Support/Message_group_"Recent_additions"

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.

Thanks.

CLOSED This issue is closed by siebrand

Rejected. Translation isn't the only workflow. There may be work to be proofread, for example.

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. :-)

OPEN This issue is open, waiting for action by pginer

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 "https://translatewiki.net/wiki/Translating:Blockly", 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.

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.

Thanks for the gracious and helpful reply.

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

Neither is this one.  :-)

There were some statistics at http://laxstrom.name/blag/2014/03/03/numbers-on-translatewiki-net-sign-up-process/ and https://docs.google.com/spreadsheets/d/1S0GhrnD9XVM6S_DlpMzkoK8kF6sn-Nd2FynrE6piEKM/edit

CLOSED This issue is closed

I'm on https://translatewiki.net/w/i.php?title=Special:Translate/ext-semanticgenealogy&language=fi&filter=&action=translate 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.

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

OPEN This issue is open, waiting for action

A feature request needs to be filed on how to cover this workflow in TUX.

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.

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

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

CLOSED This issue is closed

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.

CLOSED This issue is closed

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.

CLOSED This issue is closed by siebrand

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.

Are you talking of the mw:MediaWiki UI style?

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.

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.

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.

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

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. :-(

OPEN This issue is open, waiting for action by Nike

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.

OPEN This issue is open, waiting for action by nike

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.

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?

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

CLOSED This issue is closed by Nike

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.

Is this still current?

OPEN This issue is open, waiting for action by nike

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?

Not currently.

What about the future?

? This issue is unconfirmed, still to be investigated

We have some smaller followup tasks on Phabricator but nothing yet about whether the current system is effective at stopping spammers without harming good faith new users?

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:

• mw:Translation UX/Specification#Sign-up features
• commons:File:Translate UX Onboarding designs.pdf

Please help translating the new pages:

• Special:Translate/ext-translate-sandbox
• Special:Translate/ext-twnmainpage

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

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.

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

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.

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

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.

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.

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

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).

Now we also have some stats: http://laxstrom.name/blag/2014/03/03/numbers-on-translatewiki-net-sign-up-process/

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.