Fix translation always returning en in some cases

[glaures-ioki]

Summary

The way of determining if a translation should be taken from the app bundle or the framework bundle is slightly different. Instead of checking the preferred localisations, the app bundle is always used as the default localisation provider and the framework bundle as a backup.
Letting iOS decides which language should be used in regard to the locale, instead of manually comparing language codes and regions, fixes the issue.

Motivation

In the app we are working on, we have translations for different languages with the region designator. For example we do not support fr or nl but fr-CH or nl-NL.
I noticed that, when we use the Stripe controller to add a credit card we get the default en translation for the title instead of the localised string.
I dug a little bit and, with the phone in fr, I discovered that

[[STPBundleLocator stripeResourcesBundle] preferredLocalizations]

is returning fr but

[[NSBundle mainBundle] preferredLocalizations]

is returning fr-CH and since those two strings are not exactly the same, we get the english translation.

Testing

• The examples provided in the repo are still working as expected. I checked with the phone in en, fr and fr-CA.
• The translation of the credit card controller in our app is now working as expected
• I tried the run the tests but some dependencies associated to them are not building

[CLAassistant]

All committers have signed the CLA.

[davidme-stripe]

Hi @glaures-ioki, thank you for filing this! Sorry that it took so long to get back to you!

We're going to include this in the next release, but with a slight change: Always reading the main bundle first means a user could accidentally override our strings in an unexpected way. (For example, by replacing a string for "check" as in "paper check" with "check" as in "✔️".) Instead, we'll only use this behavior if the language codes don't match. In that case, we'll check the app's bundle first, then fall back to the Stripe bundle as you do in this patch.

I also considered checking the first two letters of the language code, but it's possible a user would still want to override our implementation in that case (for example, if we only supported pt, but a user required pt-br).

[glaures-ioki]

No problem, I saw that everything was re written in Swift so I understood that you were probably busy with more important issues.

Anyway, thank you for following up, happy to see that this will be fixed. 😀

[davidme-stripe]

We landed this in 21.2.1.