Magicmirror: Add l10n.js for localization

[paviro]

What do you think about adding something like l10n.js to the vendor folder for localizing modules? Maybe even to the module class?

getLocals: function() {
        return {
en: "en.json", 
de: "de.json"
};
    },

[MichMich]

would be a great idea ... don't really understand the concept of your function though. Could you elaborate?

[paviro]

I just thought it would be nice if there was also something to load json files, like we load css and js right now.

[MichMich]

Ah, ok ... so every module can serve it's own translations.

You could already use js files for this. But does l10n use json for this?

[paviro]

Both seems possible but I like the json idea more, since to me it's cleaner in the folder structure. js for code. css for style. json for data/translations but maybe that's just me. Of course global translations would probably also be a nice idea, at least for common words a lot of modules will use.

[MichMich]

I think it would be a good idea to built a helper around this. Which will look for a translation in a general translation file. It it isn't in the general file, it will look in the module file. This way, basic translations only need to be entered once.

[paviro]

Yes exactly and if it is nowhere fallback to english.

Am 17.04.2016 um 17:58 schrieb Michael Teeuw [email protected]:

I think it would be a good idea to built a helper around this. Which will look for a translation in a general translation file. It it isn't in the general file, it will look in the module file. This way, basic translations only need to be entered once.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/MichMich/MagicMirror/issues/191#issuecomment-211047264

[MichMich]

Indeed. I thing we should create a Translate singleton which handles this. (Just like the logger.)
I don't think we need a method which serves the files, since we should use a standard in filenames (modulename/i10n/fr.json). Maybe we need a method which will tell the system which languages are available.

getAvailableLanguages:function() {
    return ['en','fr','nl','de'];
}

Depending on the configures language (config.language) the right file will be loaded if the above methods tells us it's available.

And then use something like:

Translate.string('IDENTIFIER', 'Default translation if no translation is available.'); 

Any thought?

[paviro]

I would rename the i10n folder to locals so that it is clear to anyone even if they do not know i10n. Translate.string('IDENTIFIER', 'Default translation if no translation is available.'); seems good. My first thought was, it might be a bit long but since we probably won't have too much things to translate, it should be fine.

[CFenner]

What about a default locale for each module, so we can omit the default string?

[MichMich]

The default string would be optional. If you don't supply one, you need to put it in the default locale file (en.json).

[CFenner]

Is anyone working on this one?

[MichMich]

I'm currently not.

[paviro]

Me neither.

[CFenner]

211 just loads l10n files for each module, no overall translation file.

Any ideas how to optimize?

[MichMich]

Very nice work @CFenner. Very clean!
I've added a translation for the Dutch language and it seems to work perfect.

I made a minor adjustment to convert the language identifier in config.language to lowercase, in case someone uses NL in stead of nl.

One optimization could be to add some global translations into the project. The words "Today" and "Tomorrow" will probable be translated more often. So it would come in handy if we could use an overall translation. The module translation files could overwrite this if they want.

So, first look in the module translation file, if it's not there, look in the global one.

Any plans on adding info to the documentation?

[MichMich]

One heads up: if you are going to create a general /vendor folder, make sure to add this folder in server.js ... :)

[CFenner]

Thanks, I had a good example :)
One downside is, that the translation file must be complete. If one adds a new translation and doesn't translate all keys, for the missing keys an empty string is given, not the default (en).

I could do the doc tomorrow.

[MichMich]

Then the lookup order should be:

moduleTranslations[lang] -> globalTranslations[lang] -> moduleTranslations[en] -> globalTranslations[en]

This would probably solve the issue.

[MichMich]

Also, we might want to add an extra module property (just like classes and position) to override the global language. For example: my full mirror is dutch, except the compliments. I want those to be english.

[MichMich]

Hi @CFenner, any plans on finishing this issue?

[CFenner]

Sorry had a long weekend off, I'll do it on Wednesday.

[MichMich]

No worries! Looking forward to your pull request! :)

[MichMich]

@CFenner do you still have plans working on this? If not: no problem, but then I can search for someone willing to pick this up.

[CFenner]

That would be great, had a lot to do the last days and I think I can't work on it till end of next week.

[MichMich]

Ok. No problem.