Page MenuHomePhabricator

The title "Babel user information" always appears in English
Closed, ResolvedPublic

Description

It seems that the title "Babel user information" always appears in English, no matter what the interface language is.

Yesterday a couple of messages from the Babel extension were translated in Kabardian (kbd). I see one of them live at the first line of the Babel template at http://www.translatewiki.net/wiki/User:Beco1977 , at the kbd-N box. If i understand correctly, the title "Babel user information" is also supposed to be translated, but i still see it in English there. I tried setting my interface language to 'he', 'ru', and 'kbd-cyrl', and it keeps saying "Babel user information" in English.

See also https://translatewiki.net/wiki/Thread:Support/Babel_translation_appearing_only_partially


Version: unspecified
Severity: normal

Details

Reference
bz27793

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:28 PM
bzimport set Reference to bz27793.

It has been reverted in r83385.

And also "Users by language" is in the content language.

It is an element of page itself, so it shouldn't vary by interface language.

It is possible however, but it needs to be weighted against cache pollution , which may already be happening to some extent for other reasons.

This is a very annoying bug on Commons, where although English is the default language, many users do not know it well. In order to help them we always try to communicate with them in the language they set in their preferences. Most parts of the website interface show up in user's language, including current version of the babel template. We work hard on interface localization and for most parts users coming to commons from different wikipedias can navigate the website without knowing English. In this context insistence that this part of the interface will only show up in English feels like a big step back.

I do not understand the cache pollution issue, since this is a static text linked to the same page no matter what is the language, and we had this message localized for years with no issues as far as I can tell.

May be we can ass an extra parameter which would allow different projects choose which type of behavior is preferable on their project.

rd232 wrote:

Per Jarek in Comment 5: if you refuse to fix this, Commons may stick with the old template system. Is that what you want?

(In reply to comment #6)

Per Jarek in Comment 5: if you refuse to fix this, Commons may stick with the
old template system. Is that what you want?

Wikis are free to use or not to use this... It's mostly small wikis which benefit hugely from this extension, whereas, e.g. nlwiki hasn't adopted the Babel extension because the local system is more adapted to their wishes and works well as they want.

I'm confused why this is wontfixed. The objections that caused the revert seem to be that the commit was done wrong (Using user language without making the parser cache vary by the user language). It doesn't seem very difficult to make it use the user language and mark the parser cache as needing to vary by the user language. (This would fragment the cache I suppose, if we're really worried about that we could make it a config option, commons already has a lot of their pages varrying by user lang anyhow)

Created attachment 9499
Patch that adds (optional support) for having the babel box vary by user lang.

I'm re-opening this bug because:
*The main objections to the original commit were that wrong lang got displayed to users due to cache, not the idea of the commit.
*heck, there's even comments in the code saying fixme should use user lang
*Well in theory pages should only use content lang, Commons already massively abuses int: in order to make page content vary by user lang, this really wont add to that in any considerable way, pretending people don't do that won't make them stop.

Thus here is a patch that changes the "Babel user information", and "Users by language" messages to be in user language. It will fragment parser cache somewhat, I'm not sure how big an issue that is, but the patch makes showing these things in user lang configurable with a global defaulting to off, so if its a concern we could just enable on commons where parser cache is already rather fragmented via {{int:..

Anyhow, I'd like to commit this if there's no objections.

Attached:

done in r103786.

Commons folks who want this should get community consensus and file a new bug asking that $wgBabelUseUserLanguage be set to true for commons

(In reply to comment #11)

done in r103786.

Commons folks who want this should get community consensus and file a new bug
asking that $wgBabelUseUserLanguage be set to true for commons

Done, see bug:32726