Page MenuHomePhabricator
Create Task
Maniphest T202035

Message customization in content language is ignored when requested in course of language fallback
Open, Needs TriagePublic
Actions

Description

Message customization in content language is ignored when requested in course of language fallback

  • Customize a message, e.g. Sidebar, by editing Mediawiki:Sidebar
  • Switch user language to a different one (Using Universal Language Switcher extension, part of Translate extension package)
  • Most of the user interface switches to the user language
  • Sidebar reverts to default English content

Expected behavior: Sidebar falls back to English, finds a customized version and displays it.

Major impact of this is broken Mediawiki:Common.css when user switched their UI language.

I traced the code to MessageCache::getMessageForLang()
There, a Language CDB cache is looked up before hitting database, and, if a message is found, returns it without checking DB contents, ignoring $useDB parameter.

Simple solution would be to move CDB cache check after if( $useDB ) clause. More complex solution would be to load Language CDB cache for requested language only, excluding messages in the fallback language.

Event Timeline

Sergem1 created this task.Aug 16 2018, 3:35 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 16 2018, 3:35 AM
Aklapper added a project: MediaWiki-Internationalization.Aug 16 2018, 6:26 AM

Hi @Sergem1, thanks for taking the time to report this and welcome to Phabricator!
Do you plan to work on this task, as you prioritized it?
Which exact MediaWiki version is this about?

Sergem1 added a comment.Aug 17 2018, 2:37 AM

Hi Aklapper, I am running 1.29, but the relevant code in MessageCache.php is still the same in the main branch, so I would presume the issue is still there.

I can definitely submit a patch, but I am not sure my solution won't break things for others - my experience with hacking Mediawiki messaging system is brand new - what would you recommend?

Aklapper raised the priority of this task from Medium to Needs Triage.Aug 17 2018, 9:18 AM

Let's hope that another Language engineer / developer will take a look at this and make a recommendation. :)

Nikerabbit subscribed.Aug 17 2018, 9:28 AM

I can't follow the bug description to understand what is happening. Localised sidebars are possible and documented in https://www.mediawiki.org/wiki/Manual:Interface/Sidebar#Translations

Sergem1 added a comment.Aug 17 2018, 6:58 PM

Here is a use case:

  1. On my wiki, which has its main language set to English, I configure Mediawiki:Common.css to have large fonts, for my elder visitors.
  2. Some of the visitors switch language to their preferred language, other than English
  3. Their fonts reset to defaults and they now have issues reading the content

expected behavior: when falling back to English, the English version of Mediawiki:Common.css should be retrieved from the DB and not from the hardcoded defaults.

This issue applies to ALL messages in Mediawiki.

Nikerabbit added a comment.Aug 18 2018, 8:58 AM

Common.css does not have i18n. I think the cause here is something else than switching languages, such as message cache loading failure. Also, what version of MediaWiki? What caching have you configured? APC, Memcached, DB, Redis?

Sergem1 added a comment.Aug 22 2018, 12:32 AM

My examples we incorrect. Looks like for both Common.css and Sidebar i18n versions are ignored altogether (I am surprised to learn that, but this is off-topic).

I am experiencing issues with Tweeki skin. It has message options for sidebars and navbars (e.g. MediaWiki:Tweeki-navbar-right) and all of them reset to default "en" content once the user language is switched on the site, ignoring edits. Sidebar moves to the right, content disappears from navbar, etc. If I patch MessageCache.php , moving Language CDB cache lookup after hitting database, everything works properly - when language falls back to English from, say, Japanese, it uses edited version of MediaWiki:Tweeki-navbar-right.

Version is 1.29, production version is using APC cache, dev version has all caches disabled, both exhibit the same issue.

Restricted Application changed the subtype of this task from "Deadline" to "Task". · View Herald TranscriptAug 22 2018, 12:32 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL