Upcoming changes in registration process

Jump to navigation Jump to search

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

No, they can follow the same process. I think they can also add example "translations" to qqq if they don't know any other language? You're right about translators for new languages, this just happened with User:Paul Beppler (who was confused by not having the right to post new threads, because sandbox users are restricted) but Nike told him to translate in whatever language and I approved the account.

Personally I hope normal account registration won't be disabled, because the new process covers only a subset of all the possible cases; but anyway addition of new languages is basically frozen currently, we need a revamp and we should also update the docs on how to get appropriate permissions to write LQT threads.

Nemo (talk)08:55, 10 March 2014