Page MenuHomePhabricator

Create a directory for message keys that shouldn't be translated
Closed, DeclinedPublic2 Estimated Story Points

Description

One of the Growth team's current area of focus is campaigns - inviting new audiences to become edithors, via emails, social media ads, GLAM editing events etc. This involves hand-crafted messaging that only participants of the given campaign will see. These messages are usually needed in a few languages, but there is no point in translating them to languages in which the campaign is not exposed.

Using the standard translation pipeline for such messages will expose translators to messages the translation of which would be a waste of their time, adds noise to message lists and stats, and risks the overwriting of messages by translators who don't fully understand the context. They could be configured as optional or not-to-be-translated messages on the Translatewiki side, but that adds a maintenance and communication burden, as a new set messages is usually needed for every campaign.

A possible solution to this problem would be the creation of a new campaigns or notranslate message directory which is not registered with Translatewiki, so all message keys in this directory are ignored on that side.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
kostajh triaged this task as Medium priority.Mar 23 2022, 2:08 PM

Adding @Aaharoni-WMF and @Raymond (who have been cleaning up after us on the Translatewiki side) for feedback. Do you think this is a reasonable approach?
I guess the drawback would be that there wouldn't be an opportunity for translators to improve the messages (which has occasionally happened - these messages come from partners and shouldn't be significantly altered, but sometimes it's possible to improve phrasing), plus it would make things more confusing for community members who use uselang=qqx to debug a message and then expect to find it on Translatewiki.

Adding @Aaharoni-WMF and @Raymond (who have been cleaning up after us on the Translatewiki side) for feedback. Do you think this is a reasonable approach?
I guess the drawback would be that there wouldn't be an opportunity for translators to improve the messages (which has occasionally happened - these messages come from partners and shouldn't be significantly altered, but sometimes it's possible to improve phrasing), plus it would make things more confusing for community members who use uselang=qqx to debug a message and then expect to find it on Translatewiki.

The repo WikimediaMessages has such a do-not-transllate message directory https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaMessages/+/refs/heads/master/i18n/wikimediaoverridesnotranslate/

In consequence this message directory was not registered on translatewiki.net. Improving of phrases etc are only possible per phab task/patch.

Maybe @Nikerabbit knows a better solution.

The Wikimedia Messages repo is one good option, especially if anyone wants Growth Experiments to be reusable outside of Wikimedia sites.

Another option is to put such messages in separate JSON files and define them in translatewiki's YAML configuration as groups with limited target translation languages. It's a rarely used option, but it exists. See https://www.mediawiki.org/wiki/Help:Extension:Translate/Group_configuration#LANGUAGES

The way these messages are used is:

  • Someone wants to run a campaign (such as an IRL edithaton which starts with registering accounts, or a Facebook ad). They reach out to us and write some custom messaging that the signup screen should have (e.g. "Welcome to the Jordan Open Source Association's editathon! Your contributions will help Wikipedia grow" with a JOSA logo).
  • We create the campaign configuration (this could be an operations/mediawiki-config patch or a MediaWiki:*.json page) which defines the message keys and image, and associates the campaign with an URL parameter.
  • We create an i18n patch with the desired messages.
  • The users are sent to a custom signup link with the specified URL parameter in it, and get shown the custom signup page with the campaign messaging on it.

Usually the messages are only needed in one language, but it's not always the same language so the LANGUAGES option wouldn't be useful. And these are messages which are only used because the software is so configured (think of something like AbuseFilter's filter-specific warning messages), so they don't really affect reuse.

Moving this from the Current Sprint. We will seek help from the Language Team. More details are in this document: https://docs.google.com/document/d/1M3dVCWSSp056pW1vDYv4L-9LCEK_h2AHYOsre-K0FoI/edit#heading=h.6rxov5ttq46.

@MShilova_WMF I don't see this task mentioned in the document. Should it still go there or did the plans change?

Nikerabbit set the point value for this task to 2.Nov 2 2022, 11:54 AM

The Growth team doesn't have any further campaigns work planned, so this is no longer a top priority for us.

I checked in with the Campaigns PM and she doesn't think this work relates to any of their plans for the next year or so. So I'm tempted to decline this task, unless @Pginer-WMF thinks this task should remain open as a general localization infrastructure improvement.

The Growth team doesn't have any further campaigns work planned, so this is no longer a top priority for us.

I checked in with the Campaigns PM and she doesn't think this work relates to any of their plans for the next year or so. So I'm tempted to decline this task, unless @Pginer-WMF thinks this task should remain open as a general localization infrastructure improvement.

Thanks for checking, @KStoller-WMF. Closing the ticket sounds good to me.

We had some initial discussions internally about this task. Some ideas that came out of those are/will be filed as separate tasks.

KStoller-WMF changed the task status from Invalid to Declined.Dec 22 2022, 4:20 PM

Sounds good. I'll decline this, but I'm glad to hear that some related ideas might be worked on eventually. Thanks!