Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getString does not fallback to default Locale. #30

Open
jamescarter-le opened this issue Feb 18, 2015 · 6 comments
Open

getString does not fallback to default Locale. #30

jamescarter-le opened this issue Feb 18, 2015 · 6 comments
Assignees

Comments

@jamescarter-le
Copy link

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?

@doshprompt
Copy link
Owner

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.

@jamescarter-le
Copy link
Author

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

@doshprompt
Copy link
Owner

Thanks @jamescarter-le I will take a look and formalize it into the codebase, with tests etc. Looks good :)

@doshprompt doshprompt self-assigned this Feb 26, 2015
@cdjackson
Copy link

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).

@mehrazK
Copy link

mehrazK commented Mar 2, 2016

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().

@ssj3sunny
Copy link

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants