We need to be able to specify message fallback languages different from the standard MediaWiki fallbacks, so in Ukraine we show messages in Ukrainian or English without ever falling back to Russian. This is a i18n (cultural sensitivity) issue.
See also: T124228: Adyen in Ukrainian in Ukraine is seemingly an alternative solution for T118734 according to T135254#2326001
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Bypass built-in Mediawiki language fallbacks | mediawiki/extensions/DonationInterface | master | +42 -0 |
Change 289117 had a related patch set uploaded (by Ejegg):
WIP: Super hacky language fallback override
What's the business case for this? It seems incredibly hacky to have our own language fallback chain, and this is already a fragile area of the code.
OK @DStrine explained to me a bit. I'd like to make this change in mediawiki-core however, so we aren't maintaining separate and equal code.
Change 290362 had a related patch set uploaded (by Awight):
Don't fallback from uk to ru
I see curious arguments used here; MediaWiki (core) only accepts linguistic arguments. I gather that this is about banners again; please fix T96552 instead.
Hi @Nemo_bis, it sounds worthwhile to fix CentralNotice too, but this task is for DonationInterface, the extension on payments-wiki that serves up donation forms and error messages relating to payment processing. @awight, if you think we can get the core change merged please go ahead and re-open T39314.
DonationInterface, the extension on payments-wiki that serves up donation forms and error messages relating to payment processing
Don't most people arrive there via banners? If so, you can alter the donatewiki interface language with the uselang parameter and test if English really performs better than Russian in Ukraine.
The intent is not to force interface language to Ukrainian for all donors in Ukraine. When a donor comes in via banners, the language on the payments site will inherit from the originating project and interface language as usual.
Rather, the intent is to provide an English message rather than a Russian message when the interface language is Ukrainian but a Ukrainian translation for a particular message is not available.
Ok, then I rephrase: for $INTENDED_TARGET_AUDIENCE_OF_THIS_CHANGE, you could deliver them banners which like donatewiki with uselang set to English to see if it really performs better than Russian or Ukrainian+Russian.
Currently there is no information whatsoever to think that shoving more English onto the users would improve communication.
We're not trying to give anybody less of the language they request, but we've heard repeatedly from people who read in Ukrainian that when there is no Ukrainian version of a small part of the UI, they would rather see that part of the UI in English than in Russian.
We have more than 400 DonationInterface messages translated into Ukrainian, so the bulk of the UI will be in that language for people who follow banners from a Ukrainian language site. The intent here concerns only the messages that are not yet translated.
It seems that core has heard and rejected similar requests from the uk.wp.o community ( T39314 ).
Perhaps the best solution would be to improve the core hooks around message file contents. It is currently only possible to override those values by providing an alternate filename with the Language::getMessagesFileName hook, as I do in https://gerrit.wikimedia.org/r/289117 .
This approach requires a distinct overriding MessagesXx.php file for each language you want to change, even if you want to make the same change to multiple languages. It would be nicer to have a Language::alterMessagesFileContents hook that provided the language code and the file contents.
OK, I think I found a better hook to use - LocalisationCacheRecacheFallback runs for each language in the fallback chain including the primary. It's too late to change the fallback chain, but you can blank out data for all the intermediary ones you want to skip.
@jrobell
For the upcoming campaign, we can avoid messing with fallback order if we have our translators work on reviewing and completing the message translations:
https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-di-gc&language=uk&filter=&action=translate
https://translatewiki.net/w/i.php?title=Special:Translate&action=proofread&group=ext-centralnotice&language=uk&filter=
Yeah, having all the necessary translations in Ukrainian is absolutely what we want to do and afaik we're nearly there. @jrobell can you make sure this happens?
I think this is getting slightly confused with the main issue we had before: we couldn't add Ukrainian translations to the Globalcollect iframe, and so it was always falling back to Russian (T118734). If we're using Adyen now, that's no longer a problem.
Thanks for your work on this. I am working on getting the last translations in Ukrainian ready in on Translatewiki. (From what I can see, the copy that needs translation is not needed for our current form, but I'll get those in as well just to be sure.) As mentioned to @DStrine
earlier, it would be great if I can get the Adyen links for Ukraine sent to me as soon as they are ready, so I can have the forms reviewed by locals and make sure everything looks fine.
Thank you!
This is the Ukrainian link with country code and currency still in Ukraine but language set to Russian:
https://payments.wikimedia.org/index.php?title=Special:adyenGateway&appeal=JimmyQuote&ffname=cc&recurring=false&utm_source=.default~default~default~default~control.cc&utm_medium=&utm_campaign=&utm_key=&referrer=&language=ru&country=UA&payment_method=cc&payment_submethod=&gateway=&amountGiven=1¤cy_code=UAH&frequency=onetime&amount=Other
To be honest, if we have all the messages required for DonationInterface in Ukrainian then I think we should just abandon this task.
Personally I think the fallback should be changed in core, but let's leave that community/linguistic hot potato to the now re-opened T39314
@Ejegg, am I right: you abandoned the change because it allows not to fall back on Russian? Or was it just a description for the change? (what's the issue in there then?) Sorry, just to be clear :)
@Ata
Hi, the abandoned patch was a workaround that allowed DonationInterface (used for WMF fundraising) to fall back directly from Ukrainian to English regardless of the MediaWiki language fall back chain. We decided it would be better to fix the MediaWiki fall back, rather than trying to subvert it.
The current patch for review is:
https://gerrit.wikimedia.org/r/#/c/290362/
I still think that there is no bug here, just a misconfiguration of the banners. The solution is to prevent such misconfigured campaigns which serve untranslated banners, aka T96552: Add option (disabled by default) to force untranslated centralnotices.