[[Special:AdvancedTranslate]] protection
Special:AdvancedTranslate protection
Nothing to be done here, except perhaps enhancing enotif defaults.
I just saw edits to MediaWiki:Sp-translate-data-SpecialPageAliases/hi and MediaWiki:Sp-translate-data-MagicWords/hi both made in November 2012. Both edits are from users who are primarily involved in punjabi(pa) wikipedia. Neither has any significant contributions to hindi wikiprojects. See centralauth links [1], [2], [3]. However, both found it correct to edit special page aliases and magic words in hindi without any discussion with the hindi wikimedia community, despite the fact that they themselves can't agree over translations for punjabi [4], [5]. All the edits that had been previously made to special page aliases (by myself) had been after extensive discussions at w:hi:वि:चौपाल/विशेष पृष्ठ अनुवाद. To top this, I've just seen that the changes to special page aliases and magic words both have gone through to hindi wikipedia.
I don't doubt that the users were acting in good faith. However, changes to these translations by any user, no matter how experienced, without community discussion is just plain wrong.
I've reverted the edit to the special page aliases and plan to discuss magic word localization with hindi wikipedia community soon.
The most striking thing I find in all this is that users with no relation to a language community were able to get translations to special page aliases and magic words through to the wmf cluster without the language community getting a clue about it. I find this very disturbing. I think there should be a mechanism to verify that edits to these critical messages are performed only by community members after due discussion process. It could be via either creating a protection level for these pages with a new user group for users allowed to translate these, or just plain full protection with users only allowed to request translations at talkpages, while twn admins verify that the edits actually have community consensus before they go through. Another way could be to separate those messages which are used in the wmf cluster and protect them, while allowing changes to messages not in use on the wmf cluster.
Lastly, when will the revert to the special page aliases go to the wmf cluster?
PS:Most people in India know more than one indic language, so it is possible that a repeat of this could take place. Hence the need to consider protection seriously.
The mechanism is the usual one for wikis. Just watchlist the page and enable watchlist email notifications, tell others to do the same. Works for me. Changes to aliases are exported at intervals of several weeks or months, so there's always time to review the other people's changes.
Can't look into the history now, but please first ask those users why they changed the aliases, let's see. Also note that ideally a discussion about the aliases should happen on portal talk:hi rather than hi.wiki; you can easily open it on both and cross-link so that everyone is aware.
"ideally a discussion about the aliases should happen on language portals..."
Myself, I think that it is best to find the largest community for a particular language/software combination to discuss important changes to a localisation. For MediaWiki software the largest community for any language is usually on its Wikipedia. When a decision is made, it is possible to make a note of the decision on translatewiki.net, linked to the discussion on Wikipedia. You could make notes on the portal talk page, or you could choose to open sub-pages to the portal for localisation notes and styles, linked from the portal page. It is useful to make notes on GRAMMAR, PLURAL, GENDER as well as the aliases, namespace names, magic words and other things relevant to a language.
I couldn't agree more that the best place to discuss important changes is Wikipedia of concerned language (for MW s/w, of course). There should be some level of protection for such pages. Email notification is a good way to keep track, but it's not ideal. I'm afraid that just an email notification won't work because users may forget to check their emails.