Skip to content
This repository has been archived by the owner on Jan 29, 2024. It is now read-only.

Language setting during initialization #29

Merged
merged 5 commits into from May 7, 2013
Merged

Language setting during initialization #29

merged 5 commits into from May 7, 2013

Conversation

DWand
Copy link
Member

@DWand DWand commented May 7, 2013

It's impossible to control the exact amount of language files, which will be loaded to the user's browser at the startup phase of the application, while we specify a preferred language (which we think a user prefer) by calling a "uses" method. For example, if rememberLanguage is true browser will load one or two language files depending on a stored language code. So, it this behavior is unpredictable sometimes.
What if we provide one more property specially for setting preferred language on app startup phase? This property only know which language we prefer, but not really set it up. In such way we can fully transfer a responsibility for an initial language setting to the "run" method. So, we will be able to control which language we have to set and how many files we have to load.

knalli and others added 5 commits May 3, 2013 21:22
Add the "preferredLanguage" property in order to solve an initial language
setting issue. At the configuration phase it's better to use this property
instead of the "uses" method, because if "rememberLanguage" is set to true
it may invoke a language file loading process twice (the language from the
uses method and a stored language).
Change demo files in order to show a way of using the preferredLanguage
property.
Add simple tests for basic behavior of the preferredLanguage property.
@DWand
Copy link
Member Author

DWand commented May 7, 2013

As for tests, I don't have testing experience at all. I tried to write some tests based on other tests. But it's only basics.

@0x-r4bbit
Copy link
Member

Thanks @DWand ! Glad you made a PR, will look into this now! :)

@0x-r4bbit
Copy link
Member

I really like that one :) @knalli What do you say? I think we can merge it in.

@knalli
Copy link
Member

knalli commented May 7, 2013

Hey, a rival of my defaultKey. ;)

Technically, I'm wonder if the PR is correct because commits are split (see by travis build) and the merge commits (will that merge correctly?)

In general, I'm with it 👍 , but under which circumstances the language will be loaded twice? That case should be covered by a test.

@0x-r4bbit
Copy link
Member

Let's say you already have a cookie stored with a de_DE key, and code says $translateProvider.uses('en_US') where no translation table is available yet.

What happens is, that in the time when $translate gets injected, it auto-invokes the a loader with the en_US key. After that, ngTranslate's run() method will be called, which looks, if there is any key in $cookieStore. Now, when there's a de_DE key in $cookieStore ngTranslate uses that over what is configured before using $translateProvider.uses() .

This again, would auto-invokes a loader with the de_DE. Now two translation tables have been loaded. But you just wanted to load the one for en_US.

@knalli
Copy link
Member

knalli commented May 7, 2013

Got it. ;)

@0x-r4bbit
Copy link
Member

Awesome.

And yeah, probably it's nearly the same you did with DEFAULT_LANGUAGE_KEY a few commit cycles ago, but this PR provides a nice API.

Regarding Travis CI. If it's not merging without conflict, I'll resolve them :)

@0x-r4bbit 0x-r4bbit mentioned this pull request May 7, 2013
29 tasks
@0x-r4bbit 0x-r4bbit merged commit 772b964 into angular-translate:canary May 7, 2013
@0x-r4bbit
Copy link
Member

Merged this in. Tests have to be fixed.

@0x-r4bbit
Copy link
Member

Done.

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

Successfully merging this pull request may close these issues.

None yet

3 participants