Regarding the question of converting Twinkle into an extension, it should be noted that some of Twinkle's features have already been extensionized in the PageTriage extension. It should also be noted that Twinkle is very tied to wiki-specific templates and processes, so configuration would be a challenge.

The main priorities for Twinkle currently are:

Firstly, to keep up with process changes on English Wikipedia (for example, the recent change to submission format at WP:RPP). We can usually handle this well ourselves.

Secondly, to respond to feature requests posted at WT:TW or this repository's issue tracker. These often linger for a long time without anything being done, and in the case of requests at WT:TW, are often archived without any action being taken. We would naturally appreciate any assistance Community Tech developers may wish to provide on our feature requests, but in some sense, we would prefer that you work on more important and wholesome things :)

And finally the big one: To internationalise Twinkle so that it can be easily used on wikis other than English Wikipedia. Currently, wikis are forced to copy-and-paste Twinkle code onto their own wiki, and manually customise each module to suit that wiki's language, templates, processes etc. This obviously makes it difficult for other wikis to keep Twinkle up-to-date, and also requires the participation of a JavaScript-savvy user on that wiki. We'd like to break down these barriers and make Twinkle (a) internationalisable (allow the UI to be translated) and (b) localisable (allow each wiki to customise the list of, say, speedy deletion templates).

There is a limit to how far Twinkle can be localised (for example, a module like ARV is entirely enwiki-specific) but some of the common modules and processes like CSD, XFD (possibly), page protection, user warnings and welcomes, article tagging, etc. are commonly found across wikis and could well be localised. This is a massive undertaking, one that us volunteer developers simply have never found the time for it. It would amount to an almost complete rewrite of Twiokle, as all the strings and wiki-specific data has to be refactored out. It would also be a great opportunity to alter Twinkle to use a new Morebits.wiki.api that is JSON formatversion=2 based, instead of the XML format we currently use.

So to cut a long story short, if Community Tech was to help us with anything, it would be to allow Twinkle to be internationalised/localised more easily, and to reach out to communities currently using old versions of Twinkle to work with them to upgrade. This would have benefits for the whole Wikimedia cluster. See past discussion at the issue.

As for your other questions:

• Since it was first developed on-wiki in AzaToth's userspace, Twinkle is currently licensed under the same license as wiki content (namely CC-BY-SA 2.0). This license isn't exactly appropriate for code, and there has been some discussion about changing it to GPL, but I didn't agree with that (if Twinkle is to be relicensed at all, I think it ought to be released under a permissive license like MIT or BSD). If you would like us to change the license before you contribute, we could reopen the discussion.
• As was pointed out above, a number of Twinkle's features were reimplemented in PageTriage. However, Twinkle remains popular among users, and is community supported, unlike PageTriage, which appears to be unsupported and not being developed at present. (On a tangential note, it would be great if Community Tech could work on solving bug reports and feature requests relating to no-longer-supported WMF projects like PageTriage, …. It always makes me said to see them go unloved.)

Thanks for the interest. We look forward to potentially seeing some pull requests from Community Tech in the future!

Thanks for the information, @TTO. That's very useful. We're still very much investigating and prioritizing our early work, but I hope that we'll be able to contribute.

I'm not sure about the licensing; something more suited for code would obviously be better, but we should be able to work on it as long as there is a free license on it.

Links and information

Relevant links on-wiki:

• Docs: https://en.wikipedia.org/wiki/Wikipedia:Twinkle, https://en.wikipedia.org/wiki/Wikipedia:Twinkle/doc
• Comments/feature requests/discussion: https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle (note: TODO at top right is out of date, see first item!)

Documentation on using Twinkle mostly lives there. The talk page is generally more of a help page than an issue tracker.

On github:

• Documentation for developers and tool maintainers is at https://github.com/azatoth/twinkle/blob/master/README.md. There are also in-file comments; haven't found autogenerated documentation.

There are a handful of bugs. These range from probably small (https://github.com/azatoth/twinkle/issues/212) to more involved (https://github.com/azatoth/twinkle/issues/182, depends on AbuseFilter bug T57460).

Feature requests not currently under discussion.

• Fair number for the tagging module: https://github.com/azatoth/twinkle/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22Feature+request%22+-label%3A%22Things+to+think+about%22+label%3A%22Module%3A+tag%22
• Otherwise, looks like there are a lot of things that could be picked up and worked on.
• The FurMe merge is mentioned on the wiki as well as the issue tracker, and has been open since 2011 (https://github.com/azatoth/twinkle/issues/15). If there is interest, that could be a useful smaller(?) task. Very old branch here: https://github.com/azatoth/twinkle/tree/furme
• Huji is working on i18n: https://github.com/azatoth/twinkle/issues/129, https://github.com/Huji/twinkle. Last commit 2 weeks ago; as @TTO says, this would be a useful place for us to contribute, but a large task.

A handful of open pull requests: https://github.com/azatoth/twinkle/pulls?q=is%3Apr+is%3Aopen

On working together:

• Request for comment on the talk page: https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Interested_in_working_with_Community_Tech.3F
• Request for comment in the issue tracker: https://github.com/azatoth/twinkle/issues/290

PageTriage's Phab tasks: https://phabricator.wikimedia.org/maniphest/query/GzOS3nN6qedA/#R

There is plenty to work on, large and small, but the Collaboration team is responsible for this. According to @Catrope, there are some plans to work on curation features in Q2 but it is not certain/not likely that they will involve PageTriage specifically.

Surely localization must be a goal — why would Community Tech have to support an enwiki-specific tool?

We should investigate using JsonConfig (https://www.mediawiki.org/wiki/Extension:JsonConfig) for handling per-wiki configuration. That should make it more easily localizable (hopefully without rewriting Twinkle from scratch). JsonConfig doesn't currently have an API, but it stores everything on wiki as JSON, so you could theoretically use the mw API to pull the data and just parse it as a JSON object.

Does anyone know how Twinkle's per-wiki configuration is currently handled?

It sounds like the top priority is to make Twinkle localizable. It doesn't look like Huji has done any significant work on this (just https://github.com/Huji/twinkle/commit/be1a412410f8f2ae3fd45771721d099a7a75bb6e). The biggest hurdle here is the fact that a lot of Twinkle's functionality is tied to on-wiki templates, so localization doesn't just involve a static set of UI strings. My suggestion would be that we create an "epic" task in Phabricator for "Make Twinkle localizable" and then try to create some bite-size tasks off of that. Any concerns/objections?

@kaldari: My only concern would be whether the team is in shape to commit to an epic right now, and whether those small tasks will be useful on their own without considerable work being done on the existing gadget. But it's worth trying to find specific areas to improve.

In T108426#1540415, @kaldari wrote:

Does anyone know how Twinkle's per-wiki configuration is currently handled?

By copy-paste and manual editing of the script files :) So in other words, there is no proper infrastructure for this at the moment. Therein lies the challenge...

Before Huji came along I started work on "Twinkle Local" at https://github.com/azatoth/twinkle/tree/twinklelocal/local in an attempt to provide for the localisation of Twinkle. Note in particular that i18n and l10n are all rolled into one. The truth is, as Kaldari notes above, there are few strings that are solely tied to a language. Most strings will vary with the individual wiki, so form part of l10n.

The TwinkleLocalConfig.js file is really "JSON with comments". If JsonConfig doesn't allow comments then I would be very unhappy about using it, as comments are critical to a file of this kind.

In T108426#1541904, @Fhocutt wrote:

My only concern would be whether the team is in shape to commit to an epic right now

If it takes six months or a year (or more) for you to get to this, we won't be offended :)

The reason I have stalled on the i18n of TW is because I don't want to start it one way, spend hours of time on it, and then receive feedback that "oh, we should've done it this other way". Specifically, there are concerns about whether we should create one language file per language, per module, or per lang-module pair (I vote for the first). Also on how to implement it (should we use jQuery's i18n extension? or create our own i18n module?)

That being said, my (potentially biased) interpretation of the discussion here is that the one-file-per-lang method and the jQuery i18n extension are agreed upon so I actually intend to translate at least one module in the coming week and seek feedback.

Clearly, I agree with TTO and others that the #1 priority is to i18nize TW. The opens doors to its usage in many more wikis.

PS: If you have a better idea, please speak up! I am ready and willing to spend time on this, very soon. I do not, however, want to spend the time and then find it being totally wasted.

I'm happy to help. I don't really have much input for translation needs, but as for per-wiki configuration, I envision there being an accompanying JS config file for relevant modules. For instance, the Block module, which I wrote, goes by a big JS object of key-value pairs defining the presets available and the block options that go with them (e.g. vandalism-only account = {{uw-voablock}}, indef duration, account creation disabled, autoblock). This could be moved to a config file, that way other wikis will just have their own configuration they create, likely similar to their [[MediaWiki:Ipbreason-dropdown]]. Similarly we could do the same for other modules.

There is some enwiki-specific logic in the Block module, however. Perhaps we could remove this logic and replace it with "callbacks" or "hooks", so that developers can take advantage of them to add specific functionality for their wiki. Just a thought.

@Huji: my potentially less biased interpretation of that discussion is that you are correct on that agreement. I look forward to seeing what you come up with! If it looks like that will easily separate into tasks that others can help with, please post them here if you want to bring them to our attention.

Potential tasks for Twinkle:

• Support @Huji in i18n/l10n; first, in figuring out a direction and breaking it down into tasks.
  • Investigate using JsonConfig for this
• Clear out the bugs in the issue tracker: https://github.com/azatoth/twinkle/labels/Bug

There are plenty of smaller ones (see the rest of the issue tracker!) but these are highest priority.