Wish form localization
Open, HighPublic
Actions

Assigned To

Authored By

	Samwilson
	May 21 2024, 12:32 PM

Description

In T361512: Wish form internationalization we added i18n to the intake form; this task is to make l10n possible.

Option 1: TranslateWiki.net

This task is not to do the actual addition of the project to TranslateWiki.net (that'll be a subsequent task created following the instructions. This is just to set things up for that to happen.

One idea is that we add the messages (without Wikimedia branding) to the CommunityRequests extension, get that approved and deployed, and then use them in the gadget. Then, any Wikimedia branding (which isn't all of the messages) can be done in the WikimediaMessages extension.

The workflow then would involve:

Removing all i18n files from the gadget repo.
When you want to add a new message, it'd be added in the extension and used in the gadget — so a MR on the gadget would be dependent on a patch in Gerrit, and deployment of the gadget need to be timed to happen after the next train.
Some messages also needing changes in WikimediaMessages.

A variant of this option is to move all the messages to WikimediaMessages and not worry about CommunityRequests at this stage.

Option 2: on-wiki with the Translate extension

Create a gadget page at e.g. MediaWiki:Gadget-WishlistIntake-messages that can be marked for translation.

{
    "@language": "<languages/>",
    "messages": {
        "default": {
            "blahblah": "<translate><!--T:1--> Do blah blah</translate>",
…

This would be a wikitext page that resolves to valid JSON, and would be loaded via the API by the gadget. A working example of this is in the AddMe gadget (which also is to be merged into the intake repo, so effectively the same code can be used).

One issue with this approach is that adding new messages while in development is trickier. The dev, watch, and build scripts should be updated to push to the gadget messages page.

Details

Other Assignee: MusikAnimal

	Subject	Repo	Branch	Lines +/-
	Add messages for the CommunityRequests extension and gadget	mediawiki/extensions/WikimediaMessages	master	+82 -1

Customize query in gerrit

Title	Reference	Author	Source Branch	Dest Branch
i18n: use key name for T-markers and use nowrap attr in translate tags	repos/commtech/wishlist-intake!70	musikanimal	on-wiki-i18n	main
i18n: replace system with translatable wikitext-based JSON	repos/commtech/wishlist-intake!65	musikanimal	on-wiki-i18n	main
Move i18n messages to WikimediaMessages	repos/commtech/wishlist-intake!50	samwilson	i18n-messages	main

Customize query in GitLab

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Open		None	T363306 Wish and focus area pages translation
		Open		Samwilson	T365471 Wish form localization

Event Timeline

Samwilson created this task.May 21 2024, 12:32 PM

Restricted Application added a project: Community-Tech. · View Herald TranscriptMay 21 2024, 12:32 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Samwilson mentioned this in T361512: Wish form internationalization.May 21 2024, 12:34 PM

That sounds fine for when the extension is approved and deployed, but I suspect it will be a "while" before that happens. Perhaps we can go ahead and start porting over messages now (sans WikimediaMessages as that should be just for deployed things, I think), and this task can track that work? I'd almost rather we wait until all messages are in the gadget (focus areas and all). I suspect messages will change as we demo this more and more, so be mindful of that when upstreaming to the extension.

I don't think we should write our gadget to depend on the extension in any way. To me they are distinct and should be ship-able separately. What we definitely don't want come July is to end up with a gadget relying on an extension that hasn't been deployed.

Samwilson renamed this task from Add intake form to TranslateWiki to Make it possible to translate the intake form.Wed, May 22, 8:04 AM

Samwilson updated the task description. (Show Details)

Yes, let's go with the translatable JSON/wikitext page. I've updated the description (and will update it more later with our standard sections once I'm a bit clearer).

Samwilson renamed this task from Make it possible to translate the intake form to Wish form localization.Wed, May 22, 8:15 AM

Samwilson claimed this task.Wed, May 22, 8:20 AM

Samwilson triaged this task as High priority.

Samwilson added a parent task: T363306: Wish and focus area pages translation.

Samwilson edited projects, added Community-Tech (CommTech-Kanban); removed Community-Tech.

Samwilson moved this task from Ready 🎬 to In Development 💻 on the Community-Tech (CommTech-Kanban) board.

Using <translate> in JSON is scary. At least the opening tag should be <translate nowrap> instead of <translate> so that untranslated or outdated messages don’t get HTML markup, making the JSON invalid (e.g. the German translation of AddMe is invalid JSON), but in the short or medium term, this should use message bundles rather than page translation – message bundles are designed exactly to be JSON, but they don’t seem to have an HTTP API yet (the Scribunto interface is currently being developed in T359918, once it’s done, adding an action API should be easy).

You're right, wikitext pretending to be JSON is definitely hacky, but as you say the Translate extension doesn't yet support access to message bundles (either from Lua, or in JS where we need it; that's T238386 I think). So we're somewhat stuck with the hacky approach. Which is why I suggested adding a dependency on the extension — which is also a hacky approach, but perhaps leads towards a proper way of doing things (i.e. an extension). I don't think the wishlist project has the time to wait for the Translate extension to support an API for message bundles.

Adding a new extension doesn't really solve the timing issue either because we can't get it deployed fast enough. We could perhaps add the messages to the WikimediaMessages extension, and then copy them (all translations) into CommunityRequests so as to save translators' effort. But that's hacky too.

Change #1035024 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikimediaMessages@master] Add messages for the CommunityRequests extension and gadget

https://gerrit.wikimedia.org/r/1035024

gerritbot added a project: Patch-For-Review.Wed, May 22, 7:22 PM

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/50

Move i18n messages to WikimediaMessages

Here's a demo of the above patches that move the messages to WikimediaMessages: https://patchdemo.wmflabs.org/wikis/8850cf602a/wiki/Community_Requests/Intake

In T365471#9820819, @Samwilson wrote:

You're right, wikitext pretending to be JSON is definitely hacky, but as you say the Translate extension doesn't yet support access to message bundles (either from Lua, or in JS where we need it; that's T238386 I think). So we're somewhat stuck with the hacky approach. Which is why I suggested adding a dependency on the extension — which is also a hacky approach, but perhaps leads towards a proper way of doing things (i.e. an extension). I don't think the wishlist project has the time to wait for the Translate extension to support an API for message bundles.

I can’t speak on behalf of the Language team, but I hope the Lua access to be working within weeks, after which an action API can be developed within one-two months from now (not necessarily what T238386 envisions, but something usable). I think the page translation-based hack would be easier to migrate once Translate is ready than the WikimediaMessages-based hack, so I’d choose page translation for the time being.

Samwilson mentioned this in T365642: Localize project names.Thu, May 23, 10:44 AM

Samwilson moved this task from In Development 💻 to Review/Feedback 💬 on the Community-Tech (CommTech-Kanban) board.Thu, May 23, 10:48 AM

Samwilson mentioned this in T364959: Add terms of use checkbox to the form.Thu, May 23, 11:20 AM

samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/50

Move i18n messages to WikimediaMessages

@MusikAnimal can you update this task with current status and pull back into the Community-Tech backlog?

JWheeler-WMF edited projects, added Community-Tech (June 3-14 2024 Arctic Fox); removed Community-Tech (CommTech-Kanban).Mon, Jun 3, 6:59 PM

JWheeler-WMF moved this task from Ready for dev to Feedback and review on the Community-Tech (June 3-14 2024 Arctic Fox) board.

As the future of the extension is uncertain and we are running out of time, I think we will go with option 2. Having the deploy script handle updating messages should be doable.

I thought we'd already gone down the path of Option 1? We've got the patch ready to go for WikimediaMessages (as soon as they're stable enough to send for translation), and those messages are already being used in the gadget. (Although I've been out for a week so might not be on top of recent changes.)

MusikAnimal mentioned this in T361067: Rewrite Wishlist Survey bot.Tue, Jun 4, 7:54 AM

Indeed! I don't think there's harm in merging the WikimediaMessages when ready, given it's OK that there's not an associated deployed extension. That does however sort of us up for commitment to an extension, which I'm (again) starting to question... :( Save that discussion for when you're back! For now, given the time constraints, I think we need to stick to what's quickest and live purely in gadget land. Importing/exporting from any system is easy enough in Node.js, and we can still use translatewiki.net if we want to for some things in the gadget, etc.

At any rate, please enjoy your holiday!

Yeah that does make sense! Go for it. (I'll now return to staring out a train window.)