Distributed resource files

[demisx]

Is it currently possible to distribute resource files across multiple folders instead of placing them all under one folder off of the root path (e.g. languages/)? We are using component based file organization and would like each component to have its own languages/ directory that we'd call i18n/.

[jbertoglio]

I have been working on way to handle this as well as move the files into a database. What we do is that during development, the devs build their JSON language files in their component directory. A grunt task sweeps these up into a single file and imports it to the database. It could just as easily populate the default languages folder. We only do english as another task uses the google translate API to create an initial translation for the languages we support. That way, when we need to engage a professional translator, much of the work is done. Especially given the mundane nature of most application text. The pro can then fix by exception which saves us money and improves the product

One thing that I would like to see is a bit more public access to the localization module's internal API. I really like this tool but find that the latest versions of angular-translate have gotten past most of the objections in doshprompt's video presentation and by exposing more of the API so that we can populate the language array from a db call and/or insert one at a time.

John Bertoglio

On Mon, Dec 1, 2014 at 10:08 AM, Dmitri Moore [email protected] wrote:

Is it currently possible to distribute resource files across multiple folders instead of placing them all under one folder off of the root path (e.g. languages/)? We are using component based file organization and would like each component to have its own languages/ directory that we'd call i18n/.

— Reply to this email directly or view it on GitHub https://github.com/doshprompt/angular-localization/issues/19.

John A. Bertoglio Co-Laboratory, Inc. 503.330.6713

[demisx]

@jbertoglio Thank you for sharing your experience. Some really good points. I think you are right. I can distribute i18n/ folders with resources all over the app and then simply have gulp pull them all into one central folder at build time.

@doshprompt Would be interesting to hear your thoughts on the recent angular-translate updates and how it compares now to your angular-localization package.

[jbertoglio]

The directives, services and filters look about the same. Apparently the author of "translate" took the critique to heart. Both projects are a bit rigid in terms of data location and structure by default but translate's approach with custom data access allows us to pass data to our data store and instantiate just what is needed. Using a database allows us to search for keywords and "prune" our system as it grows. Handling multiple files times N per language supported creates a real management issue. In fact we store the language elements for each keyword in the same structure. The use of Cache (or globalsdb or GT/M or mongo) allows for data to be stored in a multidimensional manner that models complex JSON and serve back the required files for either language project.

Currently, I can work directly with translate. I have no doubt that it would not be a huge chore to modularize some of the elements in "localization" and expose more of the api. But given the voluntary/community nature of the projects, it is a lot to ask, I know. But I can use translate directly.

What would be useful is an equivalent to the instant function in translate and a method to take a JSON object that matches the basic format used by both projects to be used directly without a $http call to a text file. Briefly, our schema looks something like this:

topic.category.subtopic.keyword = Local text

an example:

login.text.all.passwordPH = "Enter your password".

The choice of language is determined by the current user preference. While I appreciate the work done in both projects to facilitate changing the locale on the fly, I don't see this as a significant requirement, at least for the uses I can anticipate. It is cool, though.

What actually happens is that the programmer requests the block of key/value pairs from a data structure something like this

"login" "text" "all" "passwordPH" [1] = "Enter your Password" [2] = "Enter your Password (in german)" [3] = "Enter your Password (in hindi)"

depending on the id of the user's selected language, the db sends back a JSON object that matches the requirements.

"all" is a placeholder node which by convention means that there is only one group of key/value pairs associated with the login portion of the project. If for some reason login was a bigger deal or a multi form process, we might have login,text[mainForm].... and login,text[additionalDataForm]... and so on to break up the elements on a more granular.

We also model the concept of "common" found in the language projects to leave stuff like yes/no and such in a server array that is persisted and not destroyed when the for or other object is destroyed.

Right now, we only use "text" and "message" as main categories. This allows us to separate static stuff like the localization of a form where all elements are required from messaging where (typically) only one string is in play at a time. This gives us the option of either loading the required message file and calling it by keyword or sending the relevant query to the db and returning the string directly. This is where the instant function is useful as it will adjudicate the replacement text parameters coded into the return string.

Once I get it fully running, we can set up a skype session and you can decide if you want to incorporate it as module.

In any case, take a look at EWD.js project on github to get an idea of how powerful the notion of directly mapping JSON and javascript object in and out of the data store.

jb

On Mon, Dec 1, 2014 at 11:10 AM, Dmitri Moore [email protected] wrote:

@jbertoglio https://github.com/jbertoglio Thank you for sharing your experience. Some really good points. I think you are right. I can distribute i18n/ folders with resources all over the app and then simply have gulp pull them all into one central folder at build time.

@doshprompt https://github.com/doshprompt Would be interesting to hear your thoughts on the recent angular-translate updates and how it compares now to your angular-localization package.

— Reply to this email directly or view it on GitHub https://github.com/doshprompt/angular-localization/issues/19#issuecomment-65117526 .

John A. Bertoglio Co-Laboratory, Inc. 503.330.6713

[demisx]

@jbertoglio Thank you so much for sharing this. Really helpful to see how you guys do it.