Please add documentation :)

[kristianmandrup]

I love your libs!!!

[patrick-steele-idem]

👍

@philidem, what do you see as the future for this module? I think this belongs as a separate i18n module with an independent JavaScript API that integrates support with Lasso.js (for transporting i18n bundles to the browser) and Marko (for providing a taglib to localize text in a Marko template).

[philidem]

I apologize for the lack of documentation! I am currently using this undocumented module but I am a little unhappy with some of the configuration to make it work. Also, the way it is now requires that each application implement their own custom tag to use the compiled dictionaries. However, maybe documenting the way it is with some of the caveats is the way to go.

I do agree with @patrick-steele-idem that part of this module should be moved to a separate i18n module because it is not Lasso specific. The "transport layer" and Lasso dependency plugin should obviously stay in this module.

I'm going to try to work on this this week.

Just to give you an idea of what this module does:

• Registers a dependency type that allows Lasso to recognize *.i18n.json files
• For each locale registered, an asynchronous package is defined that contains all of the compiled dictionaries for that locale.
• When your application starts it is responsible for loading the asynchronous package for the locale of the end-user (this works well for SPA).
• The translations for the dictionaries are placed into an i18n folder at the root of your project.
  For example, i18n/en.i18n.json would contain the English translations for all of the dictionaries.
• There are tools for translators that will refresh/rebuild the translation files based on changes that were made to the *.i18n.json files throughout the project.
• The i18n translation compiler will automatically prune strings that were previously translated but aren't used anymore.

What needs to be improved:

• Non-Single-Page-App won't really like this module the way it is now because the locale dictionaries are loaded at runtime
• For Non-Single-Page-App the application should be built for a given language. For example, http://localhost:8080/en/ would be the version of your app built for English.

[philidem]

@kristianmandrup are you building a SPA? Do you plan on loading translated dictionaries at runtime? Or do you plan on building locale-specific versions of your app? If you're building a SPA then I can probably assist you in using this module the way it is now.

[kristianmandrup]

Hi @philidem :) Thank you so much for the overview. You could just include that in the README for now. At least it would give us a chance to evaluate if it fits in our use case or not ;)
Yes, we are developing an isomorphic app which is rendered by Marko (lasso) and then some js framework takes over on the client side, connecting to the server via sockets/ajax.
Currently we are developing localstorage i18n solution, which retrieves translations from a Redis DB via REST, then syncs via sockets. Uses i18next currently, but... evaluating other options and would be nice to have the i18n json files as a fall back in any case and/or potentially even to avoid the initial ajax call.
Your thoughts. Cheers :)

[basickarl]

Sooo any documentation soon? :) Would love an example!

[philidem]

Sorry about the absenteeism and this module is long overdue for documentation. I'm still using it several for several of my own applications and it has worked quite well for my use case.

I'll get to work on this soon!

[austinkelleher]

Docs pls /cc @philidem

[ctdio]

I too would like docs added to this repo.

[Epitrochoid]

Your libs are like fine wine poured on the banks of the Rhein, but without documentation it is but a blank bottle of unknown terroir. Please correct this tragedy so that we may continue to enjoy your libs.