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.
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.
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).
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
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
@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.