why doesn't ResxToJS use the same structure as the RequireJSNet?

[gregveres]

Hi

I have just adopted RequireJSNet for typescript code in my multi-page MVC app. It works great and I have all my TS files being loaded appropriately now.

My next step was to move on to i18n. I was surprised to see how ResxToJS works. I was expecting it to follow a similar convention RequireJSNet in that I expected it to create a file of translations per page. But it appears to be creating a single large file of translations for the entire solution.

Am I missing something with how it works? I have only read this page so far: http://requirejsnet.veritech.io/i18n.html

If that is really how it works, I will try my hand at forking the project to implement the following. if anybody sees something wrong with the following approach, please let me know. I would very much like to hear from people who have better ideas. :)

The goal is to create a file per MVC controller action in RequireJS i18n format. My expectation is that these files will be quite small and we wont have to take the hit of loading the entire language for pages that only require a couple strings. I further expect that quite a bit of internationalization will be done on the server in the Razor view, but that there are times when it makes more sense to do it in the Typescript code (ie, you are providing different options on the screen based on model context).

Given that, I am thinking that I will look for a {action}-strings.json file sitting next to the page bootstrap javascript/typescript file. For example with an MVC controller called Home and an Action called Index, I would expect the following directory structure:

Scripts
    Controllers
        Home
            Index.ts
            Index-strings.json

This keeps the strings next to the code that is going to use them.

The format of the json file would be fairly simple:

{[
   ResoruceName1,
   ResourceName2
]}

ResourceName1 would be a resource name from your resource.resx file.

The rest of the configuration of ResxToJS would be the same:

• a config file to say which languages to build

• the output would go to the Nls directory.

The difference with the output would be that instead of one file called app-resx.js, there would be one file per controller action called {controller}-{action}-resx.js.

Am I missing something? Or are there suggestions that could make it a better solution? Would others use this or am I the only one that thinks loading many smaller files on demand is better than loading a monster sized file on first load and hoping that the browser keeps it in cache so that it doesn't get re-loaded every so often or on every site visit.

Greg

[aquamoth]

Did you try out your fork? As you didnt expect there to be very many translations per page I guess loading a single translation bundle for the entire site makes sense from a caching point. However, if the translations become largw I think it would make more sense to bundle parts with their respective areas, or one per page as you suggested. Myself I dont need i18n at all, but would like all these issues to move forward or get closed...

[gregveres]

HI @aquamoth

No I didn't get a chance to branch and try something like I was describing. I would still like to, but I have a very important deadline coming up that I have to put all my effort into.