Yes, we should have this. Never got round to adding it.

Same logic should apply for resolving plural rules.

+1. Thank you.

Anyone want to have a go at fixing this?

Any news about this?

I see @jpzwarte has some implementation in his fork but haven't tested it.

Given that language codes are standardised, it's probably not needed to expose it as an option. The fallback language can be derived automatically: e.g.: nl_BE -> nl.

@rubenv That's correct but I think there'll still be needed for a general fallback language and use it only if it was defined by the user. Otherwise just use the detected fallback.
To sum, with what @Akarienta said, de_DE 👉 de 👉 fallbackLanguage

@crissdev I'm not following you there. Is fallbackLanguage something configurable? As opposed to the current behaviour, where we use the (English) source string?

Given that language codes are standardised, it's probably not needed to expose it as an option.

Half a truth. There are also some languages which are very similar. E.g. if my mother lang is sk I would prefer lang cs in the app rather then en because I understand it natively without any problem (not the case of English).

I can see what I forgot to add.

de_DE 👉 de 👉 fallbackLanguage 👉 (English source string)

@crissdev This solution would be realy nice.

@crissdev @Akarienta That will only work if plural rules are equal for those languages (which we can expect for variants of the same base language).

I'd rather not support this, for two reasons:

• The goal for angular-gettext is to keep things as simple as possible. A fallback language as described above is a complex corner case not supported by other gettext implementations.
• Missing strings should be the exception, rather than the rule. If not having English anywhere in your app is crucial: don't ship before you update your translations.

@rubenv only automatic fallback by doing nl_NL -> nl is insufficient for our needs. We have specific POs which are content related, not only language related. So being able to specify the actual PO used as a fallback is a requirement for us.

@rubenv Well that's right, obviously. In fact, a user can change the language in app settings in case I am writing about (if he/she likes).

This solution would be enough then: de_DE 👉 de 👉 (English source string).

Having the fallback as above would be fine (and enough) as well.