This project is read-only.

RequireJS i18n Support

Topics: General
Jan 31, 2014 at 5:10 PM

I'm building a SPA using Typescript - everything was going very well until I started to internationalise the project. I'm using the i18n requirejs plugin to load in resources, using;

import _langModule = require("i18n!blah/etc");

...but now I have a load of;

"Build: Unable to resolve external module '"i18n!blah/etc"

compile errors which are causing multiple, bubbling compilation errors. Looking at the TS source, I can see that the directory probing algorithm is quite simple;
a) Is any "basic" support of requirejs plugins planned (like just ignoring everything before the "!" character in the path)?
b) The i18n plugin will merge modules based on the hierarchy of supported locales extensibility - the basic support above clearly wouldn't do this - so it'd be "nice" if the extended probing behaviour of the plugin could be used by the compiler...

At application run-time, I'm guessing in future b) is would be achieved by using the ECMA 6 module loader api to customise this behaviour (?), but how/will this scenario be supported on compilation with TS?

Or am I missing something obvious ;-)?

Thanks (and looking forward to v1!),

Jan 31, 2014 at 5:26 PM
Basic support exists today; take a look at the loader plugins section of Definitive Guide to TypeScript to learn how to do it. Better support in TypeScript for loader plugins is something that I’ve talked to @jonturner about in the past, so their team is aware of this issue, though I don’t currently see an open work item for it, and I’m not sure what the ultimate solution might even look like (it probably depends on the final ES6 module API as you said).
Feb 1, 2014 at 11:21 AM
I believe this workitem describes the issue: It is referenced from this discussion:
Feb 2, 2014 at 10:47 AM
Thanks both for your replys! I was aware of the amd tag - this can work, but the issue (with the i18n plugin, but I imagine others...(?)) is not just the module file loading resolution, but the bigger issue is the behavioural aspect of module resolution - the plugin will merge modules based on locale, so certain variables will exist on loaded modules depending on the client locale (which messes compilation up).

So even if I could use the amd tag/the loader ignored *!, then there may be issues. Specifically for i18n, I need to add all defs to the "root" module and add the amd tag to this, but this seems a bit of a hack.

I'd be nice if referenceResolver was aligned with and for the compiler to be configured to use the plugins using this api....