Last modified: 2014-02-27 17:02:15 UTC
If you go to mediawiki.org, Commons, or Meta if you change the default English for, say, Italiano the MediaWiki UI will change but the language of the content will stay as is, even if a full Italian version is available. In the meantime, these homepages contain huge boxes at the bottom linking to all the languages available. It makes sense to think that a user selecting Italiano wants to see as much content in Italiano by default. Luckily, if the browser is defaulting Italian then luckily the content offered will be Italian as well. Still, I don't see a reason not to default to language X for everything if the user has selected such language. This is what any normal website does. (Posted initially at Bug 30047 Comment #9)
Well there's always the {{int:.. hack. Harder to pretend like it doesn't exist if we use it on a developer wiki.
I implemented $wgTranslatePageTranslationULS a while ago. It does what the summary says, but that's probably not what you want: it does not automatically serve the content in the interface language, just when changing languages. Special:MyLanguage complements it.
(In reply to Bawolff (Brian Wolff) from comment #1) > Well there's always the {{int:.. hack. Harder to pretend like it doesn't > exist if we use it on a developer wiki. This bug is about the effects of language selection itself, not about in-page links or transclusion. For that we have bug 2085 (based on user language, to replace the int:Lang hack, mainly for transclusion) and bug 57603 (to keep content language constant) as well as bug 45096 (which is about transclusion but didn't define if constant by user language or content language).
(In reply to Niklas Laxström from comment #2) > I implemented $wgTranslatePageTranslationULS a while ago. It does what the > summary says, but that's probably not what you want: it does not > automatically serve the content in the interface language, just when > changing languages. Special:MyLanguage complements it. I've updated docs a bit. <https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector#Page_translation> <https://www.mediawiki.org/wiki/Help:Extension:Translate/Configuration#Page_translation_feature> https://www.mediawiki.org/wiki/MyLanguage
Sorry if I wasn't clear. The use case is this: Russian speaker lands in http://mediawiki.org Hopefully she will get the content in Russian thanks to browser language detection, but if she gets it in English: EXPECTED If the interface and content is in English, the user selects "Russian", and then both interface and content are shown in Russian, https://www.mediawiki.org/wiki/MediaWiki/ru?setlang=ru ACTUALLY After the user selects Russian, the interface changes to Russian, but the content stays in English, https://www.mediawiki.org/wiki/MediaWiki?setlang=ru Usually websites have a single language selector for everything, not a language selector at the top for the UI, and then a big box with languages to select the content.
(In reply to Quim Gil from comment #5) As far as I can see, this has been implemented in Translate.
Not this bug and no bug needed, but I've submitted https://gerrit.wikimedia.org/r/#/c/115879/ for mediawiki.org per comment 5. It won't eliminate the need for <languages/> at the top of the main page, to be clear.
I know it's me and I really mean it: I don't understand how this bug is fixed but then as registered user I can't get mediawiki.org to behave as described in comment #5. But I trust you and I'm happy to see that you do understand the problem. Thank you for the patch, a step in the good direction.
It's the usual distinction fixed in master vs. deployed on your wiki vs. actually *enabled* on said wiki.