Page MenuHomePhabricator

In Html::namespaceSelectorOptions(), "in-user-lang" causes LanguageConverter to be bypassed
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue:

  1. Disable JavaScript execution with browser settings or noscript extensions or (for Chrome) press Ctrl-Shift-P in Devtools and enter "disable javascript"
  2. Open https://zh.wikipedia.org/wiki/Special:RecentChanges?uselang=zh-cn&variant=zh-cn, find the dropdown menu for namespace options ("命名空间"). Note that it shows "Wikipedia讨论" for the "Wikipedia talk" (Project talk, NS5) namespace
  3. Open https://zh.wikipedia.org/wiki/Special:RecentChanges?uselang=zh&variant=zh-cn. Now it correctly shows "维基百科讨论"

What happens?:
The symptom is similar to T396231. However it is due to SpecialRecentChanges::namespaceFilterForm() passing the in-user-lang option (SpecialRecentChanges.php). With that, Html::namespaceSelectorOptions() uses the user interface language code to initialize the LanguageConverter, which can't work since the macrolanguage code zh has to be used instead.

What should have happened instead?:
Though it's an issue of the "Recent changes" page, it seems better to fix the logic of Html::namespaceSelectorOptions().

Software version: 1.45.0-wmf.13

Event Timeline

Hi @EBernhardson, I saw you authored the patch in T174057 for which this feature was originally introduced. Do you think some kind of language code prefix matching with $languagesWithVariants is doable in Html::namespaceSelectorOptions()?

Special:Search is also affected, as SearchFormWidget is created with LanguageConverter in UI language code (at SpecialSearch.php).

I actually think some kind of warning can be emitted when LanguageConverter is passed a non-supported language code that is a variant of the base language code, when $wgLanguageCode is a language with LanguageConverter. That should catch this kind of subtle error without causing too many false positives (or I might be too unfamiliar with the codebase to suggest this).