Multiple .use() calls and async rejections

[fidian]

I have been tinkering with a custom loader and found that there's a problem when you reject a promise asynchronously but do multiple .use() calls.

Let's say you are using this code with an asynchronous loader.

$translate.use('totally-wrong');  // This will be rejected
$translate.use('en-us');  // This will work

The first promise will get rejected. When it does, $nextLang will be set to undefined. When the second promise is fulfilled this $nextLang does not match and useLanguage() won't get called. When that is skipped, $uses remains undefined and then a whole world of problems crop up. Even though the language tables are defined and the keys exist, determineTranslationInstant() will have table pointing to an object whose properties are language codes, not the actual translation table. Nothing in the app will get translated.

If the rejected promise resolves after the successful one then the translations will work. It's only when the rejection happens first.

[tspaeth]

Could you please setup a Plunker on your configuration / setup so we can take a look at the case and the used setup? Thanks :-)

[knalli]

As a workaround (if possible): use the promise

$translate.use('totally-wrong')['finally'](function(){
  $translate.use('en-us')
});

So, I would say it can paint the picture:

1.01            use('totally-wrong')                   
1.02            $nextLang = 'totally-wrong'
1.03            loadAsync('totally-wrong')
2.01                                                                        use('en_us')
2.02                                                                        $nextLang = 'en_us'
2.03                                                                        loadAsync('en_us')
1.04            $nextLang = undefined
2.04                                                                        $nextLang === 'en_us' => false :(

Can you confirm?

[0x-r4bbit]

@fidian +1 on setting up a plunk so we can investigate. Thank you!

[fidian]

@knalli - The behavior you describe appears to be exactly what I was battling.

Here's a plunker. Eliminating the first $translate.use() line lets the translation work. http://plnkr.co/edit/kkGOvQTPliQmVoafsAmx?p=preview

[knalli]

Ok thanks.

[knalli]

@fidian Perhaps you can have also a look at 36710e3

1.01            use('totally-wrong')                   
1.02            $nextLang = 'totally-wrong'
1.03            loadAsync('totally-wrong')
2.01                                                                        use('en_us')
2.02                                                                        $nextLang = 'en_us'
2.03                                                                        loadAsync('en_us')
1.04            if $nextLang === 'totally-wrong' then $nextLang = undefined (not true, so skipped)
2.04                                                                        $nextLang === 'en_us' => true :)

[fidian]

@knalli - I've looked at the commit and that seems to be a good way to solve the problem. Did you update the plunker to test your change?

[knalli]

here: http://plnkr.co/edit/Or5tpacOkHf1LEpAkGJQ?p=preview (updating commit)

[fidian]

Looks like it still is not working. On load the "TITLE" should not just say "TITLE". No interaction should be required to get the title to show the UK version. As it says in the example, "If you see "TITLE" only then translation did not work."

[knalli]

Hm. It works sometimes.

[knalli]

Ok, this one works always: http://plnkr.co/edit/Or5tpacOkHf1LEpAkGJQ?p=preview (checking several times). But this one makes a change which we have to revisit first.

[knalli]

landed as d1745e4