From sprint kick-off meeting:
Support: High
Feasibility: Medium/Difficult
Impact: High
Risk: High

Priority: Normal

For the record, here are my concerns about the previous work and general observations on the topic:

• Essentially Twinkle would need to be rewritten, or at least rearchitected. A new branch should be started and work should begin on internationalising all of Twinkle that is localisable. I'm not inclined to merge any piecemeal work. The branch will be merged into master when it is finished.
• I may have an imperfect memory on this point, but I seem to recall that the difference between i18n and l10n was never clarified.
  • Using a stock i18n framework is doubtful. There is relatively little need for parameter inclusion, plural logic and the like, although I'm willing to be proven wrong on this point.
  • For most of Twinkle, using TranslateWiki is certainly wrong. (The exceptions are for modules like the diff, fluff, unlink modules that contain little or no wiki-specific logic.) This is because every wiki has different deletion criteria, names for their deletion processes, names for content pages (article vs entry vs page), and so forth. A localisation file should be provided by each wiki, on a per-wiki basis, with a single language per wiki. Since you have to have at least basic capabilities in language X to contribute on Xwiki, Xwiktionary etc, or basic English skills to contribute to the multilingual wikis, I don't see there being any need for each wiki to have more than one language for a single wiki.
  • Localisation data will be more complex than normal. A localisation file like /* Twinkle message for dewikibooks */ Twinkle.messages = { 'sharedip-title': 'Blablablabla', 'sharedip-templates': [ { name: '{{SharedIP}}', label: 'qwertyqwerty' }, { name: '{{AnotherOne}}', enableIf: function(...) { ... } }, ... ], ... }; is what I am envisaging.
• I'm sure I speak for the enwiki community when I say that I'm not prepared to accept the loss of any functionality or enwiki-specific hacks in the process. The hacks will (and, in most cases, can) be abstracted out into the localisation logic so that other wikis can take advantage of them. In the event of heavy hacking being necessary, it might be necessary to write custom per-wiki code to some extent, or perhaps even fork the modules on a per-wiki basis.

I remain confident that this will one day happen, but it will take a lot more work than most people seem to realise.

In T110148#3971849, @Huji wrote:

Internationalizing all of Twinkle and abstracting all of its logic takes a very large amount of time. Let's say 100 hours of work, plus another 20 for merging the changes to base Twinkle while that branch is being worked on. It is clear from the comment above that the chances of merging the work at any other stage than 100% complete, is 0%.

Let me soften my stance a bit there; I am likely to be able to be persuaded to merge work that is halfway complete, so long as it is clear that the underlying l10n infrastructure is solid and robust and won't be changing very much going forward. And I am not the only Twinkle committer; others may be inclined to merge work at other stages.

The "I'm not prepared to accept the loss of any functionality or enwiki-specific hacks" is a strong indicator that this task is not a priority for them.

I should be clear that my thinking is also along the lines of, Twinkle should be as customisable and flexible for other wiki communities as it has been for enwiki. And it's a low priority for us only insofar as we are not particularly motivated to work on it ourselves. That doesn't make it a low priority for the Twinkle project overall. And of course the benefit to the Wikimedia movement from globalised Twinkle is clear.

Well, you now say all the right things, but I still don't find it compelling. May be I am biased because of the unfortunate experience I had with the effort I put in it that didn't get to anywhere.

Let's hope someone else decides to pick this up. I am kind of over this already.

I think some things like the Block module could easily be translatable. Everything is already in the global scope, so for instance you could override [[ https://github.com/azatoth/twinkle/blob/master/modules/twinkleblock.js#L419 | Twinkle.block.blockPresetsInfo ]], [[ https://github.com/azatoth/twinkle/blob/master/modules/twinkleblock.js#L856 | Twinkle.block.blockGroups ]] etc., with your translations and preferred options. The Protect module is similarly designed as well. It'd be better though if these lived as on-wiki JSON files, and have Twinkle pull those in. These file(s) could also contain messages for the interface -- none of which use variables -- so you don't need a i18n framework. I also really like this because the community could add new Block reasons/options as they wish without having go through Twinkle devs, much like they do with MediaWiki:Ipbreason-dropdown (though it may attract some lovely wheel-warring :)

I agree however a rewrite of some sort is probably needed to make things modular enough to be more cross-wiki-friendly. We have to ditch jQuery.UI at some point anyway, don't we?

@TBolliger: This task is open but not associated to any active project/tag. Could you please fix that? Thanks.

If there's some generalized "community-built gadgets" tag, that's the one. Otherwise I don't know what would be appropriate. For the record, Twinkle chiefly uses GitHub for issue tracking. This one is tracked at https://github.com/azatoth/twinkle/issues/129

If this is already tracked in Twinkle's canonical task tracker at https://github.com/azatoth/twinkle/issues/129 then I'd propose to close this task as invalid.

I guess https://meta.wikimedia.org/wiki/User:Xiplus/TwinkleGlobal is some kind of start?

I have requested a Rapid Grant to take on this project. Please see https://meta.wikimedia.org/wiki/Grants:Project/Rapid/SD0001/Twinkle_localisation.