Moode Forum
[IDEA] localization - Printable Version

+- Moode Forum (https://moodeaudio.org/forum)
+-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3)
+--- Forum: Feature requests (https://moodeaudio.org/forum/forumdisplay.php?fid=8)
+--- Thread: [IDEA] localization (/showthread.php?tid=2692)

localization - bitlab - 06-22-2020

While browsing over the many forum threads I hit two requestes (from @eslei and @michdal  ) for localization of moOde. 

It isn't that hard to do, but it will take time. And it also doesn't have to be all or nothing at once.
One of nasty side effects, if you start with translation, is that you notice that English is a very compact language and that it can be needed to get a little bit more screen estate for certain texts.

There are many localization frameworks, one I really like is i18next.
It supports a lot of webframeworks including jquery.

Below is an example how this framework, client-side, can be used.

TLDR:
  1. Add the translation libraries and 
  2. Initialize it.
  3. Tag all the statics to translate (don't have to do all at once)
  4. Add translate function to text that should be dynamic translated (don't have to do all at once)
  5. Let a parser scan the files and generate the locale files.
  6. Start translating (devide the work).


1 Include the js libraries:

Code:
   <script src="js/i18next.js"/>
   <script src="js/i18nextHttpBackend.js"/>
   <script src="js/jquery-i18next.js"/>


2 Initialize it (after the document load is completed):

Code:
  i18next.use(i18nextHttpBackend) // use http to reload translation resources
       .init({
            lng: 'en',
            ns: ['main', 'config', 'translation'], // set used namespaces to load, default is no namespace which is the translation.json file
            debug: true,
            // inline translation resources:
            /*resources: {
                en: {
                    translation: {
                        "key": "hello world"
                    }
                }
            }*/
            backend: {
                // for all available options read the backend's repository readme file
                loadPath: 'locales/{{lng}}/{{ns}}.json' // path to find translation files
            }
        }).then(function(t) {
            jqueryI18next.init(i18next, $); //init jquery helper for the translation
            $(".i18n").localize(); // get all items marked for localization and localize
        })


3 Tag some static with a class to make it findable and also a translation 'key'. Can contain a namespace prefix.

Code:
<div class="i18n" data-i18n="mpd_config:audiodevice.dsd_over_pcm.label" />


4 Do some dynamic translation in javascript:

Code:
$('#mydynamiccontent').html( i18next.t('myscope.mydynamictext') );


5 Instead of a creating the utf-8 json locale files error-prone by hand we let a parser do the work:


Code:
$ i18next 'app/**/*.{js,html}'
Because most of moOde html is generated php side, use something like wget to get aparsable document.

The content of such file (on per language per namespace) generated(or updated if already exists) file:
Example of a local file with a fresh scanned key:

Code:
{
 "myscope": {
   "mydynamictext": ""
 }
}

6 Now the translation work can start by replace the empty strings. 


Offcourse the above is only fit for a hello world example, real world use requires things like plurals, array, named arguments etc.

RE: localization - Tim Curtis - 06-22-2020

Thats interesting. Good project for 7.0.0 :-)

RE: localization - rhizomusicosmos - 06-23-2020

So how much JSON will the translators need to grapple with? I'm asking because, from my experience, good translators are not necessarily good coders . . .

RE: localization - the_bertrum - 06-23-2020

(06-23-2020, 12:37 AM)rhizomusicosmos Wrote: So how much JSON will the translators need to grapple with? I'm asking because, from my experience, good translators are not necessarily good coders . . .

If the translators can supply name/value pairs in a spreadsheet or something, then transcoding that into JSON would be exactly the sort of mundane contribution the likes of I could make to the project. I dare say I could even code up a routine to translate CSV lists automatically come to that...

RE: localization - bitlab - 06-23-2020

@rhizomusicosmos I recognize what you say; at my work we even use a special language for the developers called 'dev' which should be 'related' to English, but in practive we use the tanslation 'en' to correct the dev language for normal humans ;-) In practice we use a translator (human, no domain knowledge) to create the inital translation and then use a key user (with the language as native and has domain knowledge) to correct it. Even for own native language, which is Dutch.

For moOde to support new languages, volunteers among the users are probably willing to make the translation. No developer skills required.

RE: localization - TheOldPresbyope - 06-23-2020

Quote:For moOde to support new languages, volunteers among the users are probably willing to make the translation

Indeed, from my point of view it's the willingness of volunteers to make the translations which defines the need for them.

Similarly, when a user complains about some mistranslated item, it's incumbent on that user to provide an alternative.

This brings up the question: who curates the results? On a good day I can check written German but that's the extent of my contribution. In Italian, Greek, and Japanese, I can manage to order a beer Rolleyes


Regards,
Kent

RE: localization - rhizomusicosmos - 06-26-2020

In translation, the best scenario is translating from a 2nd language to the 1st (native) language of the translator as this reduces the chance of errors and awkward syntax in the result. So, for localization of MoOde, it would be best if volunteers were translating from English to their native tongue and have a knowledge of the relevant technical vocabulary in both languages as well.

That said, I could put my hand up to translate into Japanese (my second language) if that was requested.

But as Kent has mentioned, how do we check the results? A native language speaker with the tech vocab would be best, but should you roll out localized versions before they have been reviewed as such? If so then we rely on general users to pick up the problem instances and suggest more appropriate terms.

Then there is the problem of fonts and potential problems re-formatting the interface to accommodate non-western typefaces. How robust is the GUI to changes in typeface across various browsers and platforms?

RE: localization - kepon - 11-19-2024

Hello everyone,

I'm digging up this topic.

I used this library for a software and I had taken the following part:

- No automatic translation, those who want to translate, translate into their languages.
- Even a partial translation is already good, those who want more do more
- No verification on my part, these are voluntary translations, the basis is trust and it is not "fixed" if tomorrow someone wants to correct they can correct by contributing.

Also for another software I was present on the collaborative platform https://crowdin.com/ it greatly facilitates the translation for non-coder contributors (who are put off by JSON)

Have a nice day,

RE: localization - Tim Curtis - 11-19-2024

The challenge is that this thread which was created almost 5 years ago and contained a lot of great information on how to integrate a localization framework into moode has not sparked developer interest to do the work to implement and support it.

When I say "localization framework" I'm not referring to the language translations themselves (the data) I'm referring to the modifications that would be needed to moode source code.