Loading Translation Files Per Entry-Point? about core HOT 12 CLOSED

I guess it would be better to use "set" yes.
You could also name your languages based on the type of access: "en-a", "en-b" and "en-c" and have 3 different json files for each, but I'm not sure that's better.
You could write your own loader for that as well and use "provide" in bootstrap to provide ng2-translate with your specific static loader, that might work but I haven't test it :)

from core.

Thanks for the library and the feedback

from core.

I'm fine with separate json files per module, actually prefer that.

I ended up just using Http to load separate language files for each module's route, and adding definitions using TranslateService.set, so I could hook the loading of the language into a @CanActivate annotation, to prevent the UI loading and then updating.

A custom loader wouldn't have helped me without also changing what happens inside the TranslateService.getTranslation to append key:values to the existing definitions for a particular language, or adding a method like getAndAppendTranslations. I would also need to add a way to check which modules' language files were already loaded so they wouldn't re-fetch every time that route was loaded.

It might be nice to encapsulate all that in this library, but I didn't fork/add it here because I'm not sure how common a use-case that would be?

from core.

To know the loaded langs you can use getLangs(): Returns an array of currently available langs.

I'm not sure we want to include all of that in the lib right now. Maybe if there really is other people who request it.
I'm glad that you managed to do it, I'm closing this then.

from core.

Sounds good for closing/waiting to evaluate interest. There's a key difference in what I was trying to do, versus what this library seems tooled to handle already though, as illustrated in your comment about getLangs()

This library seems tooled to switch languages for a particular UI at runtime... which seems like kind of a strange use-case to me. I have no interest in changing language at runtime (maybe not even per deployment), but I do want to support code-splitting. (multiple entry-points for a given language.)

I suspect that as web-pack code-splitting becomes more and more 'normal' use-case, this will come back up.

Thanks again for your time 👍

from core.

Yep, that's a good point.
I don't want to fall into complicated code for this lib because the official i18n lib will come soon and I might deprecate this lib by then (unless their implementation is really too complicated or doesn't fit my needs).

from core.

makes sense to me

from core.

@ollwenjones If you have a repo somewhere with an example of what you did to split up language json files for async routes, I would love to have a look at it.

from core.

@nchutchind oh man... that was so long ago and in a private bitbucket repo. I had the PR out and was basically told "let's wait until the official Angular 2 i18n is ready, so we only have to do this once."

I can see if that branch is still alive and maybe make a snippet...

from core.

@nchutchind here is the gist:
https://gist.github.com/ollwenjones/024c16e290637fd23205144f47bd300c

Warning that that branch was abandoned like beta.3, so there's some workarounds in there you don't need.

from core.

@ollwenjones Thank you for that. I was actually in the middle of writing a paragraph describing what I thought would be necessary and asking if I was close. With your gist I can see that I was in the right neighborhood, but it will help me nail it down.

Thank you.

from core.

my pleasure. good luck!

from core.