Steps to replicate the issue (include links if applicable):
What happens?:
The "about this article", "Content is available under CC BY-SA 4.0 unless otherwise noted", etc. are in English.
What should have happened instead?:
It should be in Chinese (Simplified or Traditional correspondingly).
Other information (browser name/version, screenshots, etc.):
Relevant messages are all translated on twn.net.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Bump banana-i18n dependency to fix language variant issue. | mediawiki/services/mobileapps | master | +20 -12 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | BUG REPORT | Diskdance | T359822 Page Content Service does not show Simplified and Traditional Chinese translations | ||
| Resolved | Release | hueitan | T379709 Release banana-i18n | ||
| Open | BUG REPORT | None | T385483 [BUG] Incorrect Chinese variant in infobox | ||
| Open | None | T385534 Send legacy language variant code to article footer setup |
It looks like the cause is the following:
The language code of the article contents is formatted in the BCP 47 style (capitalized zh-Hans):
<meta property="pcs:locale" content="zh-Hans">
However, the endpoint that returns the translatable messages uses the original non-BCP-47 language code (lowercase zh-hans):
{
locale: "zh",
messages: {
zh-hans: {
description-add-link-title: "添加条目描述",
article-read-more-title: "阅读更多",BCP 47 is case-insensitive, so zh-hans is by definition the same BCP 47 code as zh-Hans. See https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1 which says:
At all times, language tags and their subtags, including private use
and extensions, are to be treated as case insensitive: there exist
conventions for the capitalization of some of the subtags, but these
MUST NOT be taken to carry meaning.
More precisely, it looks like the Banana-i18n library is being (incorrectly?) case-sensitive about the language code.
https://github.com/wikimedia/banana-i18n/blob/master/src/messagestore.js#L50
It works when initialized with the lowercase zh-hans locale, but fails (falls back to English) when initialized with zh-Hans.
I'm not a maintainer of that library, but I believe it needs to be released as a new version on npm, so that other projects can start using this new version. (Looks like @abi_ might know?)
This PR was merged and was part of the v2.3.3 release of banana-i18n already: https://github.com/wikimedia/banana-i18n/releases/tag/v2.3.3
I've fixed the release notes for v2.3.3 which did not mention this before.
On the npm repository, the version 2.3.3 was published "3 years ago".
Are we sure this latest version was published properly to npm? (Did the version number need to be bumped, so that the npm version becomes 2.3.4?)
You are right. While we published a version on GitHub, the same was not published on npm. Please use 2.4.0 available now on npm.
Change #1101868 had a related patch set uploaded (by Dbrant; author: Dbrant):
[mediawiki/services/mobileapps@master] Bump banana-i18n dependency to fix language variant issue.
Change #1101868 merged by Cooltey:
[mediawiki/services/mobileapps@master] Bump banana-i18n dependency to fix language variant issue.
@Diskdance This is now deployed. Would you be able to verify this on your device?
(You might need to refresh the article in your app, and/or clear the app's cache, to make sure any cached javascript is reloaded)
@Dbrant From my testing, this particular problem has been solved, but another problem arose.
For zh-cn locale in the Android app, everything is working fine. But if I switch to zh-tw locale, it is showing Simplified Chinese (zh-hans, superset of zh-cn) translations.
I guess there are some problems in the fallback chain? Could you please help check that?
EDIT: It seems https://zh.wikipedia.org/api/rest_v1/data/i18n/pcs is missing translations for zh-hant. Is it the cause?
You are correct -- This URL just needed to be purged from cache. Please try it one more time!
Now in zh-tw, text at the bottom of the page show Traditional Chinese version correctly, but the infobox title ("Quick facts" and "More information") still shows Simplified version. Is this still a cache issue? It persists until now.
Hello @Dbrant, the issue described above is still occurring, can you please check what's wrong? Thank you.
@Diskdance Sorry for the delay; I was OOO for a bit.
I'm definitely seeing the issue you describe, but I can't actually reproduce it locally (i.e. the service works correctly on my machine), which likely points to a caching issue. I will ping Content-Transform-Team for their thoughts, and also ask @cooltey to reproduce locally, just to make sure I didn't miss anything.
Per discussion with @cooltey, this issue has been fixed on the Android side. A patch for the iOS app is working in progress.
Thanks so much @Diskdance for raising this issue and for helping with the fix - here are the two iOS tickets that have been created to fix this on our side: T385483: [BUG] Incorrect Chinese variant in infobox & T385534: Send legacy language variant code to article footer setup. We might not be able to pick up these right away, but they are on our radar.
It looks like this issue has been tackled on the client side. Removing our team. Feel free to re-add if there is something that we need to fix on the server side.