Timing issue when using angular-translate-loader-static-files

[rkoch]

I've run into something that looks like a timing issue when retrieving the current language during bootstrapping when there aren't any translation tables loaded yet. I am using the local-storage plugin and the static-files loader.

I wanted to validate if the stored language is valid in the .run() function using $translate.uses(). As it needs to load the remote translation file first the language is not applied and the method just returns undefined. If I have the translation tables locally there is no problem at all - but unfortunately thats not an option for me.

I created a plunk to reproduce the issue: http://plnkr.co/edit/EPr9bU?p=preview
I logged the output of $translation(Provider).uses() during .config() and .run() to the console.

Can you look into that?

[0x-r4bbit]

Hey there! Will take a look at it tomorrow once I'm in the office!

[rkoch]

Great, thanks. Let me know if you need further information!

[knalli]

Yeah, that's actually correct.

Look at https://github.com/PascalPrecht/angular-translate/blob/c09d1dbe71d4260c1e88c6b21cf9987175bc2a0f/src/translate.js#L515-530 you will see that $uses will be set after and if (and only if) the translation loading process was successful.

I think it's not ideal to return a value (of $uses) which isn't "confirmed". But we could perhaps introduce something like $proposedUses or better $proposedLang.

[DWand]

Hi, @rkoch. Maybe, it's better to use another way to validate that?

As I remember, the uses() method is used to set a needed language or to get a language, which is currently in use. But, like @knalli said, the module does not load any language during config phase. Such behavior was realized because you can change a target language many times during this period.

Based on your example, I think, these variants might be useful:

1. create an array of supported languages (only language codes) and use it in validation process (instead of providing a whole translation table)
2. do a HEAD request to the server to check if a needed file exists

[DWand]

Hmmm... Maybe, it makes sense to add a method like isLangExists or something like that.

[rkoch]

@DWand I actually already found a workaround - I am watching for the event translationChangeError and do a language reset (based on browser prefs) then. I think this is even better than my previous approach in .run(). But it would be cool if the plugin gets that a language does not exist and doesn't even start a request.

@knalli I think you are right about not returning a value which isn't confirmed. But $uses could always return a promise (not just when used as setter) so if it is in the middle of a language change, it would defer until that's done. Of course a $proposedLang would do the job as well!

[knalli]

But Not in the existing API $uses? Then again, we would have to
introduce something new like getLang.

[0x-r4bbit]

Sorry guys, hadn't enough time to take a deeper look at the issues. I think what @DWand said is a bit toooo much just to check the currently used language. And yea $translate.uses() returns undefined as long as it isn't set.

I like @knalli 's idea to introduce a new API for that, but I think we could get around this, without even introducing a new API.

First, we need a private property like $proposedLang or something like that. $translate.uses() as well as $translate.preferredLanguage() make use of this property, by setting it's values by given lang key through $translate.uses() or $translate.preferredLanguage().

Now, when a lang key is requested through $translate.uses() it returns the value of $proposedLanguage when $uses is undefined. So sth. like:

$translate.uses = function (key) {
   if (!key) {
      if (!$uses) {
          // $uses is probably not confirmed yet
          return $proposedLang; // this is always set!
      }
   }
};

What do you think about that?

[knalli]

That would change behavior of $uses(). How to get a "confirmed" language?

[0x-r4bbit]

@knalli When the "confirmed" language is set, speaking of $uses it would return $uses. If not, it'd return $proposedLang (or whatever we want to call it)

[0x-r4bbit]

Argh. Okay, you're right. In the case $translate.uses() would fail somewhere, it would return a value which isn't confirmed and never will be. Sorry, guys didn't think about that.

[0x-r4bbit]

If it's only about the initial language to load, @rkoch could just use $translate.preferredLanguage() to get the key, but this wouldn't help out when the language key has been changed during runtime..

Okay, looks like we really need a new method for that =/ hmpf..

[rkoch]

@PascalPrecht why not always return a promise in $translate.uses()? In the case that no change is pendent the promise would be instantly resolved with the language stored in $uses. This would also normalize the interface between getter/setter as both would return a promise then.

[0x-r4bbit]

Yea I was thinking about that too, but this would break the existing API when comes to just asking for the currently used language.