Second load from failed (404) static files load reads from internal tables instead of retrying the actual file load

[brokenalarms]

http://plnkr.co/edit/309zz2RGQmtmDAoD8q21?p=preview

You load a file using static files loader, and if the file doesn't exist, it fails, gives a 404, and does not change the language (expected). However, if you load it again, angular-translate must have loaded the undefined result into internal translation tables, because pressing it for the second time will bypass the static files loader (can be confirmed by placing a console.error in that module's error function) and the keys will be loaded instead.

The desired behaviour should be that if there is a 404, the request to load a language should keep going through the static files loader until successfully loaded into angular-translate's internal table.

Cheers!

Daniel

[tspaeth]

hm. Is the plunker showing this "negative" case? It's just the normal 2 language-switch-success-case, or?

Regarding your request:
Well. That depends. If you get a 404 on a static resource, the module currently thinks that there is no resource to load. In case of server side / resource application errors which might be fixed in the meantime, your concern will sound right, but as for me, I don't want the application to hammer the server hundreds of times just because "it might be there some time". That's useless traffic and delaying your app as it has to "try & error resolve" always.
But if you really need it - this feature could go into a configurable or customized behavior / pluggable module with a configuration parameter or whatever.

So if you'd like to see that in the module - we'd be glad if you want to provide a nice modular PR for this if there are not more users voting for this. :-)

[brokenalarms]

Oh, I'm sorry, the changes I made weren't saved into the plunk. I don't think this made the problem clear - I am not talking about having the StaticFileLoader automatically try and load the file.

Try this:

http://plnkr.co/edit/HzHnAJIzurSh4oJbQADb?p=preview

Very simply, I set the language to English on first run. The DK file is not present. Click on the DK option once, it reads from the StaticFilesLoader, which correctly generates an error return to the promise (put console.error in the StaticFilesLoader JS to see this. The second time you click on the DK option, the behaviour should be exactly the same - the first fetch by the StaticFilesLoader was a failure, so the language file is still not present and should be prevented from loading (which would show the keys).

However, there must now be an actual undefined table registered for DK internally by angular-translate, as on the second click the StaticFilesLoader is bypassed entirely, the (presumably) undefined internal table is read, the language change is reported as a 'success'...and the keys are shown on the screen.

It seems to me that the StaticFilesLoader should not be bypassed until it hands angular-translate a at the least present and preferably non-empty language file, and that a simple error check is missing in this regard (but I don't have the skills (yet ;) to be able to see where exactly angular-translate reads from the StaticFilesLoader and determines it has 'successfully' received the language from it.

[knalli]

Internally, the reason for this is that langPromises will store a promise for each (requested) language key -- forever.

We could fix this with 9f1b0d1, but I'm currently not quite sure I have not omitting something. /cc @angular-translate/core

[knalli]

@PascalPrecht @tspaeth @DWand nicely ping :)

[tspaeth]

Do we have any testcase for this addition? 😄

[knalli]

As the latest activities here show, some additions has been made.

Closing this.