Open siddharthvp opened 3 years ago
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.
@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?
It's up to users in twinkle-zhwiki. For non-zh users, it's zh-hans according to language fallbacks.
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.
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;
@Xi-Plus Yes that should work.
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?
Because we had built all zh-* i18n files, I didn't override language
variable in messenger.ts
.
What we could do is to put
language
in theTwinkle
object (namespace) intwinkle.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.
I found I need some way to override the language variable. It sounds good.
@Xi-Plus Done in e78e9ee.
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
msg
function, usemsgc
for content lang messages andmsgi
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 usewgPageContentLanguage
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?