Handle content language and user language being different

[siddharthvp]

Twinkle presently can be configured to emit all messages in a single language – which can be configured but defaults to the wiki's wgContentLanguage. Ideally, strings shown on the interface should be in the user's preferred language (wgUserLanguage) and strings saved to the wiki (in page texts/edit summaries) or used to scan page texts should be in content language.

Likely approach

• The i18n library we use (https://github.com/wikimedia-gadgets/orange-i18n) already enables us to use multiple messages stores which can be set to different languages. (Notably, mediawiki-native i18n modules – mediawiki.JQueryMsg and jquery.18n don't allow this).
• Use two message stores. Fetch all messages for both content lang and user lang. English messages continue to bundled in source (don't need to be fetched) to serve as the fallback for both. In the i18n json files, no distinction is made between content lang messages and interface lang messages.
  • Alternatively, to prevent having to fetch all messages for both languages, we could have two i18n json files for every language. Off the top of my head, this shouldn't cause issues with translatewiki.net or anything else.
• Instead of a single msg function, use msgc for content lang messages and msgi for interface lang messages.

What about multi-lingual wikis? Multi-lingual wikis have a single wgContentLanguage, usually English. Twinkle will use that rather than trying to use wgPageContentLanguage which can vary per-page.

Caveat

The per-wiki customisations will usually contain many messages. Since we don't expect people to use i18n while writing localisations specific to their wiki (at least https://github.com/wikimedia-gadgets/twinkle-enwiki doesn't), this means that only those interface messages that come from twinkle-core are shown in the interface lang. This results in interfaces with mixed-language interfaces.

This is the reason why I didn't pursue this from the beginning. Is this reason enough not to bother with handling contentlang—userlang duality?

[Xi-Plus]

Since we don't expect people to use i18n while writing localisations specific to their wiki (at least https://github.com/wikimedia-gadgets/twinkle-enwiki doesn't)

There are language variants for some wikis, e.g. zhwiki. We need to apply i18n function to all messages (e.g. wgULS in twinklefluff.js#L72 ). So we need to support i18n for wiki-specific messages.

[siddharthvp]

@Xi-Plus I see. What language does zhwiki use for page content, edit comments, etc? Is it up to users on whether to use zh-hans or zh-hant?

[Xi-Plus]

It's up to users in twinkle-zhwiki. For non-zh users, it's zh-hans according to language fallbacks.

[siddharthvp]

Ok, so I don't see an issue for your use-case. tw core exports the language variable and it can be changed. So what you can do in your localisation file is:

import {language, init} from './core'; // import from tw core

language = mw.config.get('wgUserLanguage') === 'zh-hant' ? 'zh-hant' : 'zh-hans'; // this must be done before init() is called

As for the wiki-specific messages, you can continue to use that wgULS system. Or if desired you could use orange-i18n itself. Let me know if there's an issue I've overlooked.

[Xi-Plus]

I hope I can store zh-hans and zh-hant messages in different files. Just like twinkle-core do. So I need to check user language in twinkle.ts, right? Like this:

import messagesHans from './messages-zh-hans.json';
import messagesHant from './messages-zh-hant.json';

Twinkle.messageOverrides = mw.config.get('wgUserLanguage') === 'zh-hant' ? messagesHant : messagesHans;

[siddharthvp]

@Xi-Plus Yes that should work.

[siddharthvp]

Ok, so I don't see an issue for your use-case. tw core exports the language variable and it can be changed. So what you can do in your localisation file is:

import {language, init} from './core'; // import from tw core

language = mw.config.get('wgUserLanguage') === 'zh-hant' ? 'zh-hant' : 'zh-hans'; // this must be done before init() is called

@Xi-Plus Did this work? I realise now that this would give an error (https://stackoverflow.com/questions/45997225/error-ts2539-cannot-assign-to-c-because-it-is-not-a-variable/50298966). Sorry should have checked before suggesting. What we could do is to put language in the Twinkle object (namespace) in twinkle.ts, so that it can be changed from the client twinkle. Does that sound right?

[Xi-Plus]

Because we had built all zh-* i18n files, I didn't override language variable in messenger.ts.

[Xi-Plus]

What we could do is to put language in the Twinkle object (namespace) in twinkle.ts, so that it can be changed from the client twinkle. Does that sound right?

I found I need some way to override the language variable. It sounds good.

[siddharthvp]

I found I need some way to override the language variable. It sounds good.

@Xi-Plus Done in e78e9ee.