Last modified: 2013-04-22 16:14:51 UTC
See analysis in the URL.
This should be a deployment blocker IMO.
Hard to block deploys since AFTv5 is already deployed. :-) It's a deployment blocker if we ever really expect to leave enwiki (and maybe dewiki, though some of these might be revealed in dewiki: my guess is they haven't because the extra messages create more load in the translators, and Matthias already speaks German so the lack of documentation didn't stop him).
(In reply to comment #2) > It's a deployment blocker if we ever really expect to leave enwiki (and maybe > dewiki, though some of these might be revealed in dewiki: my guess is they > haven't because the extra messages create more load in the translators, and > Matthias already speaks German so the lack of documentation didn't stop him). You seem to be making a fundamentally flawed assumption, Terry. We allow setting all languages in each wiki. A user can use a UI in English Wikipedia in Arabic, in Hebrew, in German, or even in Dutch. The fact that developer Matthias, tech savvy, and very familiar with terminology and functionality, was able to translate the extension without additional documentation is a moot argument to not provide excellent documentation for crowd sourced volunteer translators. It doesn't stop them, but it does lead to a much lower quality than possible.
I am aware. And they will have a broken experience (currently) when they switch language UIs. But at this point it can't a deploy that has already occurred. My point was having additional (useless) strings and a lack of message documentation will be an issue going forward but wasn't revealed during the dewiki pilot because the developer spoke German already. So there are some stuff that will be caught because of the pilot and there are some stuff that won't be. The dewiki pilot doesn't solve AFT's i18n/l10n problems. AFT was started a long time ago. AFTv5 was started over a year ago by outside contractors. Language support was one of the things that was deferred and we're living with the consequences of that now. We're aware, but at this point there is nothing we can do but make time for this bug during the current plan. Matthias is trying to fit that in.
(In reply to comment #2) > Hard to block deploys since AFTv5 is already deployed. :-) Heh, I know. :) I meant "blocker for wider deployment than en.wp and de.wp" actually, sorry for being so short-worded.
Andre, Totally cool. Luckily the state of the codebase makes it a blocker on ops end as well. I'm sure Matthias will deal with 90% of these in the process of refactoring (or while waiting for the code review on the refactor) so I'm not above making it a blocker for wider release (there are other enwiki specific things that also would need to be addressed).
https://gerrit.wikimedia.org/r/#/c/38314/ should fix the remaining issues
(In reply to comment #7) > https://gerrit.wikimedia.org/r/38314 should fix the remaining issues It looks like this changeset was merged by Siebrand on January 23. Marking this bug resolved/fixed, accordingly. I have no doubt that Nemo will re-open this bug if he feels there are unresolved issues here. :-)
(In reply to comment #8) > (In reply to comment #7) > > https://gerrit.wikimedia.org/r/38314 should fix the remaining issues > > It looks like this changeset was merged by Siebrand on January 23. Marking > this > bug resolved/fixed, accordingly. I have no doubt that Nemo will re-open this > bug if he feels there are unresolved issues here. :-) Actually I only filed this bug as pointer to a report by Santhosh (almsot a year before this bug), I'm not qualified to judge properly the status of AFT i18n and I don't know whether Santhosh or other Language engineering team members will feel it's worth writing another such analysis.
