Page MenuHomePhabricator

Make Twinkle localizable to any wiki [AOI]
Closed, InvalidPublic

Tokens
"Like" token, awarded by Force_Radical."Like" token, awarded by Liuxinyu970226."Like" token, awarded by Hello903hello."Like" token, awarded by He7d3r."Like" token, awarded by MarcoAurelio.
Assigned To
None
Authored By
kaldari, Aug 25 2015

Description

Per T108426, it would be awesome if Twinkle could be localized for wikis other than English Wikipedia. Since Twinkle is very tied to wiki-specific templates and processes, this is going to mostly involve creating an on-wiki configuration system (perhaps using JsonConfig) rather than a traditional i18n architecture. See T108426 and https://github.com/azatoth/twinkle/issues/129 for more discussion on this.

https://en.wikipedia.org/wiki/Wikipedia:Twinkle - Documentation
https://github.com/azatoth/twinkle - Code repo

Event Timeline

kaldari created this task.Aug 25 2015, 1:18 AM
kaldari raised the priority of this task from to Needs Triage.
kaldari updated the task description. (Show Details)
kaldari added a project: Community-Tech.
kaldari added subscribers: kaldari, TTO.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 25 2015, 1:18 AM
kaldari moved this task from Untriaged to Blocked on the Community-Tech board.Aug 25 2015, 1:18 AM

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

Priority: Normal

kaldari triaged this task as Normal priority.Aug 25 2015, 6:16 PM
kaldari set Security to None.
kaldari moved this task from Blocked to Ready on the Community-Tech board.Aug 25 2015, 6:20 PM
kaldari moved this task from Ready to Tracking work by others on the Community-Tech board.
kaldari added a project: Epic.
kaldari updated the task description. (Show Details)Aug 26 2015, 12:07 AM
Huji claimed this task.Sep 12 2015, 2:06 AM
He7d3r added a subscriber: He7d3r.
DannyH renamed this task from [AOI] Make Twinkle localizable to any wiki to Make Twinkle localizable to any wiki [AOI].Oct 28 2015, 7:05 PM
Huji changed the task status from Open to Stalled.Feb 14 2018, 2:00 AM

Until there is active support by the lead developers of Twinkle, this is going nowhere. It is impossible to internationalize and localize Twinkle in one go, and if there is no interest in accepting partial pull requests, then we will be stuck in a stalemate forever.

TTO added a comment.EditedFeb 14 2018, 2:58 AM

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.

Huji removed Huji as the assignee of this task.Feb 14 2018, 2:20 PM
Huji added a subscriber: Huji.

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.

Agreed. But I don't think even a separate branch will ever be merged. See comments below.

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.

Creating yet another i18n framework that only returns message strings using their keys is pointless. We can use an existing i18n framework, and not use some features like plural or gender. Why reinvent the wheel?

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.

This is exactly where the problem lies.

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

This is a lot of work that is not needed by the enwiki community; they are just fine with a non-internationalized non-localized Twinkle and couldn't care less. Since, in my humble opinion, Twinkle lead developers seem to consider enwiki as their primary customer, they will set their priorities accordingly. 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.

As a matter of fact, I am de-assigning myself from this Task. I am willing to be convinced to work on this, but that would require a notable shift in the way Twinkle code base is being governed.

I remain confident that this will one day happen

I remain confident that this can happen one day. But the barrier is not technical.

TTO added a comment.Feb 14 2018, 11:12 PM

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.

Huji added a comment.Feb 15 2018, 12:40 AM

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 Twinkle.block.blockPresetsInfo, 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.

MusikAnimal closed this task as Invalid.Mar 5 2018, 4:57 PM

Yeah, I think it was only migrated to Phabricator because of Community Tech's possible involvement. Probably safe to say as a team we won't be working on this (but I hope to as a volunteer :). Closing as invalid as suggested, please re-open and tag if you disagree.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptNov 11 2018, 6:53 AM