wikimedia-gadgets / twinkle-core

Core for localised versions of Twinkle
Other
4 stars 5 forks source link

Handle content language and user language being different #4

Open siddharthvp opened 3 years ago

siddharthvp commented 3 years ago

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

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 commented 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.

siddharthvp commented 3 years ago

@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 commented 3 years ago

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

siddharthvp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@Xi-Plus Yes that should work.

siddharthvp commented 3 years ago

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 commented 3 years ago

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

Xi-Plus commented 3 years ago

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 commented 3 years ago

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

@Xi-Plus Done in e78e9ee.