wikimedia-gadgets / twinkle-core Goto Github PK

It's hard to apply i18n on it.

For example:

footerlinks = {
    'Twinkle help': 'WP:TW/DOC#batchundelete'
};

I want to change 'Twinkle help' to msg('twinkle-help'). But object keys cannot be a function. I hope it will be

footerLinks = [
    [msg('twinkle-help') as string, 'w:WP:TW/DOC#batchdelete'],
];

or

footerLinks = [
    { label: msg('twinkle-help') as string, page: 'w:WP:TW/DOC#batchdelete' },
];

When Twinkle is deployed as a user script rather than as a gadget, loading the twinkleconfig file and i18n messages can be done in parallel with fetching of the twinkle source file. This should make userscript deployments almost as fast to load and initialise as the gadget deployments.

In many languages, timestamps are always formated in 24-hour-style, for example:
9:00 instead of 9:00 AM and 21:00 instead of 9:00 PM.

Please:

• Add support for this
• Inform about how to use the 24-hour-style in the translatewiki.net message documentation.

Messages that should support 24-hour timestamps include:
this, this and this

If it's already supported, you just need to inform about it

Thank you!

At the moment Config.ts is a mess with English hard-coded strings for preference texts, and also the hard-coded enwiki-specific CSD criteria data.

Also:

• The setPortletConfig function from portlet.ts may better belong over here.
• Some cosmetic improvement in the GUI construction was done in wikimedia-gadgets/twinkle#1321 which should be ported here.

There are two message definitions with trailing whitespace.

Trailing whitespace is not supported in translatewiki.net (because it's not supported in MediaWiki pages).

Please remove the trailing whitespace. If it needs to be preserved, try to do that in the code instead of the message.

Wikimedia:Twinkle-prompt-reason-restore/en
'Please specify a reason for the       | 'Please specify a reason for the      
revert:                                | revert:'                              
'                                      |                                       

Wikimedia:Twinkle-summary-prompt/en
'An optional comment for the edit      | 'An optional comment for the edit     
summary:                               | summary:'                             
'                                      |                                       

Orange-i18n is currently being bundled as part of twinkle source code. It could be made a separate (hidden) gadget (like select2 and morebits).

I have override portletName in this way:
https://github.com/Xi-Plus/twinkle-zhwiktionary/blob/7582f78403302babe9cee5da635947dfe825376e/src/batchdelete.ts#L5
The text in the menu is still "D-batch".

export class BatchDelete extends BatchDeleteCore {
	portletName = '批刪';

doesn't work too.

Currently speedyCore.ts has a lot of English Wikipedia specific code and configuration.

JS string i18n libraries used on MediaWiki are all typically written for use in the wgUserLanguage rather than the wgContentLanguage. This poses a problem for Twinkle since many of our i18n string usages are in edited text; and edits saved to wikis should be in the content language of the wiki.

mediawiki.language is a collection of utilities but doesn't offer a message parser. Also, it's based on wgUserLanguage, whichc can't be changed.

mw.Message and mw.jqueryMsg

• Locale is wgUserLanguage and can't be changed.
• Offers magic words like ns, formatnum, SITENAME and many others
• Offers HTML parsing, with built-in safeguards to stop XSS attacks

jquery.i18n

• locale can be changed from the wgUserLanguage default. It is a global variable
• Available as a ResourceLoader module

banana-i18n

• Not available as a RL module. Needs to be bundled alongside Twinkle using webpack.
• Locale can be specified.
• formatnum templating not supported. Digits are always rendered as Arabic numerals.

i18next

• External (non-WMF). Popular js library.
• Does not use the "banana" message templating format which is used on MediaWiki and which translatewiki.net folks are familiar with.

Likely options: jquery.i18n and banana-i18n.

jquery.i18n vs banana-i18n

• Both use the familiar "banana" message syntax
• Locale specification in jquery.i18n is a global. Any other script can modify the locale and Twinkle would break. Banana-i18n uses a class-based system so that we remain in control.
• This is same as jquery-i18n, except that this doesn't rely on jquery. The DOM-related functions are missing, which we don't need. This is the more modern library and is actively supported.

Issues with banana-i18n:

• For plural rules parsing, it relies on Intl.PluralRules which isn't supported on IE 11 and Safari <13.
  • Solutions:
    • mediawiki.libs.pluralruleparser is available as a ResourceLoader module. Use a modified version of the the library that uses it instead.
    • Use v1.1 of the library which instead uses cldrpluralruleparser npm package and the plural rule data stored in a JSON file.
    • Drop support for for these browsers.
• Does not translate numerals (also a problem with jquery-i18n)
  • Solutions:
    • Patch the library to add support for this.

None of these libraries appear to support the mw.language.listToText-like function in messages. This makes it seemingly impossible to localise strings of the form "Added tag1, tag2 and tag3 to article" (here, the number of tags is variable).

Greetings! I was intrigued by twinkle starter, and I wanted to adapt other parts of Twinkle to hrwiki.

I'm attempting to have the CSD module work on hrwiki, but I'm having a problem:

I've adapted tagging for CSD, and it works fine, but actual deletion fails.

The error happens in SpeedyCore.ts in line 513 onwards - the messages being requested by getPref() in that part of the code do not have their default values defined in Config.ts - defaultConfig object. As a result, getPrefs returns undefined, and undefined.indexOf(norm) obviously fails.

Please help me resolve this. Thank you!

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?

The portlet has been updated to fix display with vector, but the version wasn't bumped, so it's still incorrect on for things that use twinkle-starter (like my in-development twinkle-commons). Bumping the version and creating a new release should fix this.

Not that I think it is of any use, but just for feature parity with https://github.com/wikimedia-gadgets/twinkle.

Currently WarnCore.ts doesn't support the auto-level mode (implemented in the original repo in wikimedia-gadgets/twinkle#777).

i18n deployment workflows are failing: https://github.com/wikimedia-gadgets/twinkle-core/actions/workflows/i18n-deploy.yml, so newly added/updated translations are not getting synced to Gerrit.

When I set my language to zh-tw, Twinkle failed to load messages and fallbacks to en. It's better to load zh-hant messages.

Fallback sequence: zh-tw, zh-hant, zh-hans, en.

Some info: https://www.mediawiki.org/wiki/Manual:Language#Fallback_languages

While async-await is I think currently usable in twinkle clients, it is not currently being used in twinkle-core at all. The reason is mainly that the webpack/babel transpile async-await to generators, which are awkward and can be hard to debug.

However, async-await can simplify things quite a bit and make code more readable in many places.

Not relevant to English language, but nevertheless the official recommendation is to explicitly use it even in English as the syntax guides translators.

The API would need to be used to fetch user genders and pass them into the i18n. Not sure how feasible this is. Would require quite a bit of code changes in modules.

• Tag
• XFD - translations remaining
• speedy - msg translations remaining
• fluff
• warn - autolevel support missing
• block
• protect
• batchdelete
• diff
• batchundelete
• unlink
• Config [not a module]
• batchprotect

No localisation needed; add only to twinkle-enwiki:

• prod
• deprod

Temporarily port to twinkle-enwiki only, think about implementing in core later:

• ARV
• Welcome
• talkback
• Shared IP

4 messages are using this syntax. Orange-i18n treats $1 as an operation name and fails. Will probably be better to tweak the library as using HTML entities here (}}$1) may make the message confusing for translators.