Page MenuHomePhabricator

Injected info does not get translated
Closed, ResolvedPublic

Assigned To
Authored By
Pginer-WMF
Jul 15 2019, 9:07 AM
Referenced Files
F29869092: image.png
Jul 25 2019, 12:17 PM
F29869096: image.png
Jul 25 2019, 12:17 PM
F29869094: image.png
Jul 25 2019, 12:17 PM
F29869090: image.png
Jul 25 2019, 12:17 PM
F29774038: photo_2019-07-15 11.05.37.jpeg
Jul 15 2019, 9:07 AM
F29774040: photo_2019-07-15 11.05.33.jpeg
Jul 15 2019, 9:07 AM

Description

When accessing contents through external translation services, we inject labels and info that are provided in the user language. However, due to a recent regression, the contents appear untranslated.

Checking this example the current and previous states are shown below:

Current (text in English on a Hindi translation)Previous (text in Hindi on a Hindi translation)
photo_2019-07-15 11.05.37.jpeg (1×606 px, 95 KB)
photo_2019-07-15 11.05.33.jpeg (1×606 px, 99 KB)

Event Timeline

@Krinkle Need an advice from you on this.
We have a requirement to show some UI messages in a language that is not wgUserLanguage. That may be surprising, but the context is Google translated page as shown in above screenshots. Eventhough the wgUserLanguage is translation source language, the real user language here is translation target language. So if user is reading an English wikipedia page, translated to Hindi, the messages we show should be in Hindi, even if wgUserLanguage=='en'.

ResourceLoader adds lang parameter to the module load query strings, and that lang param is wgUserLanguage. Before https://gerrit.wikimedia.org/r/c/mediawiki/core/+/518466 I could change the wgUserLanguage before an mw.loader.using call to desired language and get the messages in desired languages. This was a dirty hack, no wonder why it stopped working now. But what is the right and clean way to get the message and module in a given language?
I was considering using the source param in module definition:

'source': 'local', (or) 'anotherwiki'

where the anotherwiki pointing to target language wiki, but again lang param in query will be wgUserLanguage and that is not what we need.

This is not something currently supported in ResourceLoader. The workaround may've worked in limited cases, but would also have been broken due to localStorage caching taking precedence (when you change wgUserLanguage and call mw.loader.load(), a previously loaded module from the "real" user language would be used from the browser cache if available).

Implementing something like this natively would require significant amount of work, something to schedule together in a future quarter or annual plan at some point.

For the time being, I can only recommend a suboptimal alternative workaround, which is to export the needed messages as a data module for multiple languages (the ones you currently run the feature against, if not too many...).

E.g. the data could export messages like { message-key: { lang1: value, lang2: value } } and then client-side access the one you need, with a fallback to the content, user, or En language (your choice). This will make the payload bigger, but this is the only way to do it currently that I can recommend.

Change 525521 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ExternalGuidance@master] Provide the messages in the target language of translation

https://gerrit.wikimedia.org/r/525521

Thanks @Krinkle. The usecase is not a widely used one to justify an effort to implement this feature. At least for now. For now, I used a workaround as https://gerrit.wikimedia.org/r/525521

We provide the messages in source language itself and remove our 'notranslate' attributes so that Google MT will translate the messages to target langauge. Not optimal, but better than giving messages in a language the user don't know. The source messages comes from the localization of interface messages to that source language.

Bundling all required messages may not be an option since we allow all languages with this extension. And these messages should be rendered as soon as the page is ready and rendered on top of article.

Some screenshots after the patch:

image.png (390×706 px, 41 KB)
image.png (390×706 px, 49 KB)
image.png (369×708 px, 40 KB)
image.png (369×708 px, 38 KB)

I suppose that is indeed still a workaround, as you call it. But, I must say, that's a brilliant solution!

Change 525521 merged by jenkins-bot:
[mediawiki/extensions/ExternalGuidance@master] Provide the messages in the target language of translation

https://gerrit.wikimedia.org/r/525521

Change 526637 had a related patch set uploaded (by KartikMistry; owner: Santhosh):
[mediawiki/extensions/ExternalGuidance@wmf/1.34.0-wmf.15] Provide the messages in the target language of translation

https://gerrit.wikimedia.org/r/526637

Change 526638 had a related patch set uploaded (by KartikMistry; owner: Santhosh):
[mediawiki/extensions/ExternalGuidance@wmf/1.34.0-wmf.16] Provide the messages in the target language of translation

https://gerrit.wikimedia.org/r/526638

Change 526637 merged by jenkins-bot:
[mediawiki/extensions/ExternalGuidance@wmf/1.34.0-wmf.15] Provide the messages in the target language of translation

https://gerrit.wikimedia.org/r/526637

Mentioned in SAL (#wikimedia-operations) [2019-07-31T11:52:20Z] <kartik@deploy1001> Synchronized php-1.34.0-wmf.15/extensions/ExternalGuidance: SWAT: [[gerrit|526637|Provide the messages in the target language of translation (T228019)]] (duration: 00m 46s)

Change 526638 merged by jenkins-bot:
[mediawiki/extensions/ExternalGuidance@wmf/1.34.0-wmf.16] Provide the messages in the target language of translation

https://gerrit.wikimedia.org/r/526638

Mentioned in SAL (#wikimedia-operations) [2019-08-01T11:19:08Z] <urbanecm@deploy1001> Synchronized php-1.34.0-wmf.16/extensions/ExternalGuidance/: SWAT: rEEGU9402c36f7964: Provide the messages in the target language of translation (T228019) (duration: 00m 56s)