Accept-Language de-DE does not end up using de.all.json

[nuarhu]

Hi!

This might be similar to #30 but that issue is quite old so I'm rather starting a new one here. I'm not sure it's completely related.

My setup

• de.all.json
• en.all.json

I am using simply de and en because there is just one translation for each language, no flavours and I want them to be used for any kind of locales of those languages that come along, be it en-GB, en-US, de-CH, de-DE, etc. Default language is en in any case, and I really want to get the English text if the German version should not be found for some reason (which best should never happen).

The issue

With Accept-Language header de-DE, the de translations are not found.

This is becauselang.MatchingTags() is only applied when adding translations (so in my case de, en, and of course the matching tags are only de and en).
When the translation function is requested for de-DE, only lang.Tag is used to lookup the fallback language and this is then only de-de (in bundle.translatedLanguage()).

So, my question is, would it not make more sense to use lang.MatchingTags() also in bundle.translatedLanguage() where the fallback is looked up?

[iainduncani]

I come from a Java world so I was surprised by this as well. In Java if you had the files:

en.all.json

Then en and en_US etc. would both match to that file whereas if you just had:

en_US.all.json

Then en would not match it but en_US would so the opposite of the matching rules here. I can see some merit of matching to more specific languages (i.e. en -> en_US, although I'm not convinced this will work for all languages) but think that the opposite should also be supported...

[iainduncani]

I just read through the very informative and interesting:

https://blog.golang.org/matchlang

Looking at what the golang.org/x/text/language package does it's matcher is much more comprehensive than either the one here or the one I knew from Java... For instance if en_US is the only supported English locale then en_US, en_GB and en will all match to it (as will Albanian!). I wonder if this project should switch to using that for it's language matching...

[nicksnyder]

I agree that it would be ideal for this project to depend on golang.org/x/text/language for matching.

So, my question is, would it not make more sense to use lang.MatchingTags() also in bundle.translatedLanguage() where the fallback is looked up?

There is probably some low hanging fruit as you describe (which was mentioned in #30) for making the current matching slightly better. I am open to PRs for this. Right now I don't have time to allocate to this.

[nicksnyder]

Also related: #44

[nicksnyder]

v2 contains a proposal to fix this. See #92

[nicksnyder]

More specifically, it relies go golang.org/x/text/language

[nicksnyder]

I just tagged 2.0.0.beta.1. Please start using it and report any issues that you have.