Internationalization and Localization

[sbat]

Please optimize your framework for international requirements.

[meaku]

i'll try to find some suitable modules and discuss them with @jhnns

[topa]

I like the idea that the translation is also some kind of a model, which is binded to the view.

[meaku]

I did some research... We had a simple approach for the BBC but i'm not sure if it is really fitting our requirements.

BBC-way

• include a node-module for each language and file with subfolders for each language
• include this file in the view depending on the language used i.e. require("en/myView.js")

Problems

• as views are classes they are being compiled, and we can't decide which language to deliver on the server while rendering
• we will need a special require for the language file to load the suitable file/module on the client for each user
• there are missing features like pluralization and data-formatting

Other Modules

• Very basic approach: might be enough for the beginning
• i18next : based on jQuery, many features, completly client-side
• i18next-node: i18next for server-side use
• datejs: for international date-stuff

[meaku]

Found on tumblr

var __ = (function() {

        var translation = {
            "by": "von ",
            "(default)": "(Standardeinstellung)",
            "This page overrides a built-in URL.": "Diese Seite überschreibt eine eingebaute URL.",
            "Edit HTML": "HTML bearbeiten",
            "Custom theme": "Benutzerdefiniertes Template",
            "Use": "Anwenden",
            "Saving...": "senden...",
            "You have unsaved changes.": "Du hast ungespeicherte Änderungen",
            "Updating...": "Update läuft...",
            "Update preview": "Vorschau aktualisieren"
        };

        return function(string) {
            return translation[string] || string;
        };

    })();

[sbat]

@meaku could be interessting for you:

https://webtranslateit.com/en/projects/3020-Diaspora WebTranslateIt is a translation tool to help translate documents and software from a web browser.

[meaku]

Thanks @sbat! This really looks nice!

I checked which file-formats they are supporting and it looks good :) File Formats

JSON hash - As used by i18next and i18n-node libraries

So we should focus on i18next as it seems mature and would work with the webtranslateit

[meaku]

But the services is not for free: https://webtranslateit.com/en/plans

Maybe there is a free service...

[sbat]

500 segments are for free. But yes @meaku maybe there is a free service!

[meaku]

This one looks interesting: https://www.transifex.net/plans/

[meaku]

Should i18 be part of alamid or is it up to the application developers? @sbat @jhnns @topa

[topa]

I see i18n as some kind of rendering. Our Views are able to render data from Models. I think we should find a way to use these mechanism also for i18n, because it already exists and works just nice. Maybe we introduce a special data-label='de_beer'. (=) Before a Page or View is displayed it's nodes will be scanned for this attribute and some kind of a fancy Translator will return a Model that contains the translations for the current language.

MightyPageChanger.changePage("anyPage");

//In the changePage()
needTranslation = jQuery(anyPage.getNode()).find("[data-label]")

translation = TranslationService.get(needTranslation)

Then there will be a Schema created out of the translation which will be set for a Model. This Model will be bound to the Page.

alamid should provide this mechanism and the app-devs must implement the service.

[jhnns]

Internationalization is very tricky because there are problems that we might don't know about yet. For instance, some languages have multiple plural forms. E.g. the plural is different if you have 2 beers or 3 beers. Therefore alamid should not have a specific framework baked-in because there is no framework that fits for every use-case. But alamid should offer a good way to costumize its behaviour.

I think there are already good ways to implement i18n. For instance: you could use the constructor of a DisplayObject. There you can walk over the node and inject all translations. Therefore it would be reasonable to extend the DisplayObject so you don't have to take care of that for every DisplayObject you implement.

[topa]

The problem @jhnns has mentioned can be solved by a good naming for the labels. But you'll have a lot of quite redundant translations.

[meaku]

So it should be up to the developers to take care of i18n in the first place. I'll leave this issue open because we should check out how it works for us with our alamid-based projects.

[sokra]

Since you are using webpack: https://github.com/webpack/i18n-loader

[meaku]

@sokra: you i18n-loader looks nice! We might implement it.

There are still some problems with i18n that still have to be solved, like language specific date-formatting and the like.

[sokra]

The i18n-loader just provides some basic stuff for internationalization and you can extend it to your demands.

date-formatting may be solved like this:

// format.js
exports.date = function(d) {
  return d.getFullYear() + "/" + d.getMonth() + "/" + d.getDate();
}

// de.format.js
exports.date = function(d) {
  return d.getDate() + "." + d.getMonth() + "." + d.getFullYear();
}

var dateFormat = require("i18n/choose!./nls/format").date;

[jhnns]

It's definitely worth a try. Maybe we can use the i18n loader in conjunction with another i18n framework.

[sokra]

:) It should be flexible, but the internals are not very well documented. Do not hesitate to ask me.