Page MenuHomePhabricator

Invalid locale sent to new Ingenico API
Closed, ResolvedPublic2 Estimated Story Points

Description

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.

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.

Sent an email to merchantservices asking them to clarify

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

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

Ejegg triaged this task as High priority.
Ejegg moved this task from Backlog to Review on the Fundraising Sprint They Live board.
Ejegg set the point value for this task to 2.

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

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

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

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

@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

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