Localization is important

One of the larger obstacles in using material (books, software, etc.) from outside Latin America in Latin America is that it is usually only provided in English.  Unfortunately, many young students don't speak, read or write anything but Spanish, so it's important to think localization into solutions for this region from the very beginning.

With the technologies I have settled on for the Education Kit, this becomes an easy task for some parts and require a more creative solution for others.

The Client

Because the custom web client is written in pure Qt5 (C++ and QML), localization becomes quite easy here:

• Wrap all strings to be translated in qsTr("...") (some extra hacks needed to get QML to swap language on the fly)
• Modify the .pro file to inform which languages we want to translate to
• Run lupdate to create/update translation files for each selected language
• Give some nice red wine, chocolate and QtLinguist to the translators - and wait for the result
• Run lrelease to produce compact binary versions
• Enjoy! :)

The Server

As we would like the server to keep the settings and generally be able to dispatch any global configuration to remotely connected browsers fetching exercises, the server needs to support a few things:

• Getting the chosen setting information from the QML client
• Some way of storing the settings
• Provide the settings to connected web clients (both the custom client's WebView as well as remote clients, e.g. tablets, phones and more)

As a first shot, to get the information from the QML client to the node.js server, I chose to do a simple XHR from QML:

    function selectLanguage(value) {

        language.selectedLanguage = value;

        var req = new XMLHttpRequest();

        req.open("POST", "http://127.0.0.1:3000/settings/language/"+value, true);

        req.send();

    }

NOTE:  This will probably change to some cleaner direct socket call.

There is a corresponding handler on the server side:

    app.post('/settings/language/:value', edukitapps.setLanguage);

And now store and dispatch the information to all connected clients (using socket.io):

    exports.setLanguage = function(req, res) {

        var language = req.params.value;

        console.log("Setting language to: " + language);

        selectedLanguage = language;

        res.send("Setting language to: " + language);

        if (_io !== 0) {

            _io.sockets.emit("language", {language: selectedLanguage});

        }

    };

The Exercises (WebApps)

All visible texts in the exercises are surrounded by span tags with unique IDs, e.g.:

    <h1><span id="txt_color_mixer"></span></h1> 

When the application loads, it will include a settings.js javascript file that is auto-generated on the server side to include all kinds of user settings (for now - just the language):

    exports.getSettingsJS = function(req, res) {

        var str = "// This is the auto-generated settings from the server\n";

        str += "var _LANGUAGE = '" + selectedLanguage + "';\n";

        res.type("application/javascript");

        res.send(str);

    };

Inside the exercises, the language information can then be used to set the text strings, e.g.:

    function setStrings(language)

    {

        if (language === "es") {

            $("txt_color_mixer").innerHTML = "Mezclador de colores";

        } else {

            $("txt_color_mixer").innerHTML = "Color Mixer";

        }

    }

NOTE:  A more elegant solution is in the works - and it will most probably be based on pure socket.io .

Even if the WebApps are running in a WebView (WebKit2) in the custom built client, there is currently no easy way of for the QML to communicate directly with the content when changes happen as there was in the case of QtWebView (WebKit1) - or at least I haven't found any ;).

Therefore, the sequence of events happening from the user pushing a language selection button to the exercise visually changing the text strings is the following:

1. The user selects a language in the QML client
2. QML sends an XHR call to the server
3. The server notifies all connected WebApps of the change using socket.io 
4. All connected WebApps, including the one running inside the custom client, gets the notification and can act upon it

It may sound a bit complicated, but the result is instant and the code to handle it is simple on both server and client side.  Here is the required handler code in the WebApp:

    socket.on('language', function (data) {

        setStrings(data.language);

    });

What about the source code?

 This gets a bit more complicated to keep localized as the code should remain readable and functional.  However, it should also be OK to require for future software developers to learn a bit of the technical English they will encounter anyway if they choose to become proper developers.

The comments should be kept in a very clear and simple English - with the possibility for small extra translations in complex places.

NOTE:  This may change though - based on the feedback from future pilot tests in Latin America.