@cscott Hello, as the extension has passed security review I believe it's time to proceed with attempting to at least deploy it to beta. Are you willing to do reviews for this? If not, could you help with finding the right sponsor?

Security review passed, going to send CLs to enable extension in beta cluster.

Yep!

We had no need since autoconfirmed users got hardly any added permissions (all logged in users could move pages, for example.)

In T404461#11428904, @cscott wrote:

Is this task going to be that "production deployment tracking task"? If so, perhaps you could edit the task description to include a checklist such as that described on mediawiki so we can keep track of progress and what still needs to be done. (Otherwise you could open another task to be the tracking task.)

In T404461#11424175, @cscott wrote:

In T404461#11411552, @Aklapper wrote:

See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for requirements.

Expanding on this: it would be good to have https://github.com/tbodt/mediawiki-MultiTitle moved to gerrit, and a README.md written for the repository. The checklist also includes the process to getting the extension supported by translatewiki. I note that the i18n/ directory does not have a tok.json although MultiTitle.i18n.magic.php includes an entry for tok.

I'd also recommend that the magic words in MultiTitle.i18n.magic.php be made case-sensitive (first entry in the array 1 rather than 0); cf T389029: Case-insensitive parser functions/magic words should be deprecated.

Basically, despite the checklist saying "get a WMF steward first", I think there's a little bit of work needed first. When you get to https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment#Preparing_for_deployment Content-Transform-Team is willing to give reviews and otherwise facilitate.

In T411234#11415471, @YoshiRulz wrote:

Also affects e.g. isiZulu.

It's time?!

Hm, theoretically, but now I'm worried about this task getting stuck for an indefinite period of time and having to live with the regression. Ideally I'd like to at least get the commitment to host the extension before we create the wiki to avoid that.

I thought so, since the pages that use it would be broken otherwise. But it sounds like this is more of a task for between creating the wiki and opening it (like importing pages?)

I haven't done the work because that page says to get someone willing to provide WMF stewardship before doing anything else. I can own going through the process if I get the go-ahead.

(It is a dependency, what's the best way to mark that?)

In T397999#11084668, @Aklapper wrote:

In T397999#10959526, @cscott wrote:

to simplify Extension:MultiTitle and get it adopted by WMF

If there was a request to deploy MultiTitle on Wikimedia servers, then https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment should be followed (which will require moving off Github, having WMF stewardship, etc etc) instead.

In T398755#10976590, @Winston_Sung wrote:

• BCP 47 language subtag: tok (Toki Pona)
• BCP 47 script subtags: Latn (Latin script), [unassigned] (Sitelen Pona script)

Is this correct?

One wrinkle is that sitelen pona is not yet in unicode and so hasn't been assigned ISO 15924 code yet. Is this a blocker?

I imagine it would be necessary to add an item to the language definition for a list of previously used default date formats, so DiscussionTools can create parsers for all of them.

if you wanted this to be a uniform feature of articles on toki wikipedia, you don't need the explicit keeptitle page property, you could just make this a configuration variable. That would shrink the already-small Extension:MultiTitle by quite a bit, since a lot of what's going on at the moment is just boilerplate related to the keeptitle magic word.

Would like to request a backport to 1.39 LTS which I am running

Or maybe it can render on Page/en or whatever the page language is. Ultimately meaning Page/en and Page get their rendering swapped

In my mind, that's something you don't usually need to do, so it would be fine as a URL parameter or a special page or something similarly unintuitive. But is there something I'm not thinking of? Probably...

Had a possibly very good idea: have the main, untranslated URL for the page render in the user's UI language. Then all the links can just be normal unmodified links to the main page URL!

I'll send a gerrit change(s) with the json file(s) later.

I suspect it actually should be added to https://gerrit.wikimedia.org/g/translatewiki/+/master/LanguageSettings.php instead.

I'm trying to figure out how to submit translations for Toki Pona, but it's missing from the dropdown on Special:Translate. Should it be added there?

Some translation work has been done recently starting with the old /tokipona data, which can be found here: https://github.com/tbodt/mediawiki-tokipona/. It would be better to delete the tokipona data and import this instead.