Looks like the createHostedCheckout method doesn't like locale=zh-ha. Let's nail down the list of acceptable values and make sure we're sending one of those.
Description
Details
Event Timeline
Weird, https://epayments-api.developer-ingenico.com/s2sapi/v1/en_US/java/hostedcheckouts/create.html#hostedcheckouts-create-payload says that
If you submit a locale that is not setup on your account we will use the default language pack for your account.
but it's returning 400 BAD REQUEST in this case.
Reply:
The 'locale' has to match the correct format which two lower case letters (LanguageCode ISO) follow by a '-' and then two upper case letters (Locale). For example, en_GB (English) and zh_CN (Chinese).
Getting lots of failmail. This should be pretty straightforward, so let's pull it into sprint.
Change 465192 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Fix staging for donor locale
Oh hey, we're getting some errors where the language code sent was 'yue', staged to 'yue_CN' then trimmed to 'yue_C'... Will need a slightly different fix for that one. Apparently yue should mean Cantonese, and is often encoded as zh_HK according to http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/05/picking-the-right-cantonese-la.html
So, the IANA subtag registry has an entry for 'yue' with propery 'macrolanguage: zh'.
There's a project on github that parses the registry to PHP, but the project isn't available in packagist and doesn't indicate a license.
Change 465192 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Fix staging for donor locale
Did I really say 'pretty straightforward' on a human-language-related issue? :P I think @awight approached this before and decided we should be using the language tags internally. Looks like we've got a repo set up for a fork of a package to handle BCP-47: https://phabricator.wikimedia.org/diffusion/WFLT/
Or, something we can maybe use when we're on PHP7: https://packagist.org/packages/whitecube/lingua
Change 466930 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Special 'yue' => 'zh' fallback logic for IngenicoLocale
@Ejegg Looks like this just got a little tricker. We've got Ingenico failmail for another failing locale 'vls_B' which according to https://iso639-3.sil.org/code/vls is West Flemish and spoken in Belgium. I'm wondering if the 'E' from BE is being dropped due to field length constraint?
It looks like we might be able to map this to 'nl-BE' which is Dutch, Belgium. What do you think?
Thanks for pointing that out, @jgleeson! I parsed all the 3->2 fallbacks from mediawiki core language code and from the IANA registry, and ended up with this: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/DonationInterface/+/466930/2/ingenico_gateway/IngenicoLocale.php
Hope that covers most everything we're likely to see.
Change 466930 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Special fallback logic for IngenicoLocale