angular-localization
angular-localization copied to clipboard
doshprompt
getString does not fallback to default Locale.
Love the framework, excellent job.
I have a question about the fallback locale.
I have an en-GB set of lang.json files which work just great. I want begin to create an ar-AE locale, but so far I have just done one lang.json file.
However, what I would expect is that if the getString cannot find a bundle for this locale, it should use the fallback locale to try and find the token.
If not, it means that I must add tokens to each language when I add a new string, otherwise they will read %%KEY_NOT_FOUND%% rather than the fallback language, english.
Do you have a change in the works for this?
That's in the roadmap, but for now the solution is to use grunt-angular-localization which will generate a mirror of your default locale for the ar-AE locale except it won't mirror strings that you have already overridden. So there will be some more files that you will need to check in but the files will always remain up to date. I guess you can put the task in to run during the deployment or build stage of your app.
Please let me know if this helps, otherwise I will work on the proposed solution asap.
Hi Rahul,
Thanks, I haven't had the time to modify your base files and add tests, but I've implemented this sufficient for my requirements here: https://gist.github.com/jamescarter-le/5ee99719b8c2a8271920
It falls back to the default locale if there is not a token in the current locale.
Kind Regards, James
Thanks @jamescarter-le I will take a look and formalize it into the codebase, with tests etc. Looks good :)
I haven't fully followed this through, but just a thought - does this account for the fallback locales (I don't think so)?
In my way of thinking, the fallback should be hierarchical - specified local first, then fallback local, then default local.
So, you might have - de-CH, de-DE, en-US (so Swiss German, then German, then English).
Looking at the code, I think the fallback locale is only processed when we set the locale on startup (or at least not on every conversion).
Hey guys, we're having the same issue in our project. Any update on when this fix is going to be in? At the very least, please support one fallback language for getString().
