Implement i18n in OpenAmbit

[bubulle]

An interesting feature would be implementing internationalization so that the program dialogs, menus, messages, etc. can be localized to various languages.

Being a C++ app, I suspect this is mostly about using gettext features for this but even though I'm involved in FLOSS localization for years, I don't have much clues about The Right Way to do it, not being skilled in programming, myself.

[paddy-hack]

@bubulle From what little I've seen of the code below src/openambit (which contains the code for the GUI), it is using Qt's tr() for user visible strings already. So the I18N part should be (mostly?) there. All that would be needed is to get these strings into some kind of (Qt) message catalog (which proably needs someone familiar with Qt and CMake) and translated (which is L10N and needs translators). I'm a gettext() user myself so cannot really help much with the message catalog stuff. For translations, I could do a (possibly quite horrible) Dutch and Japanese one.

[paddy-hack]

@svenstorp, @mbernasocchi and @battila What do we use for libambit messages, if any? What internal string encoding do we use for things coming in from the outside that don't fit the ASCII mould? USB devices may provide translated strings. File systems use their own encoding, independent from the process'. I'd rather decide this now than go hunt for breakage later.

FYI, GTK+ uses UTF-8 internally for everything except file system entries. These you have to convert explicitly yourself before showing them to the user. Basically, strings are converted from the encoding specified by the process' LC_CTYPE to UTF-8 when entering the program and back again when leaving. In between you can safely assume UTF-8. No idea what Qt does but I guess something similar (they're not using UTF-16/32, are they?). If Qt uses UTF-8 internally, I suggest that libambit does the same:

• strings coming in are converted to UTF-8 from whatever the process' locale settings dictate
• strings going out are converted from UTF-8 to whatever the process' locale settings dictate
• file system entries are exempt from this. The file system's encoding is a property of the file system and not of the process. If necessary, a suitable environment variable may be consulted.

[bubulle]

Quoting Olaf Meeuwissen ([email protected]):

@bubulle From what little I've seen of the code below src/openambit (which contains the code for the GUI), it is using Qt's tr() for user visible strings already. So the I18N part should be (mostly?) there. All that would be needed is to get these strings into some kind of (Qt) message catalog (which proably needs someone familiar with Qt and CMake) and translated (which is L10N and needs translators). I'm a gettext() user myself so cannot really help much with the message catalog stuff. For translations, I could do a (possibly quite horrible) Dutch and Japanese one.

I don't really have much clues about implementation of localization in
such context.

On the l10n side, though, being myself involved quite deeply in
Debian's i18n activities, I can easily gather a significant
localization effort from Debian translators, in several languages, all
of them by native speakers.

And I can do the part for French myself, definitely.

[svenstorp]

Yes, for the Qt-parts we (should) use tr() for all strings already. There are a few small codelines to add to get it all running, but it is "almost" there. For translators Qt have a quite nifty tool called Qt Linguist. You can read about Qt Internationalization at http://qt-project.org/doc/qt-4.8/internationalization.html.

For libambit I agree on UTF-8. Except for the strings coming from USB-listing (product, serial, etc) we also handle strings from "inside" the Ambits which has their own encoding (ISO-8859-1 it seems). They also needs to be converted to UTF-8. The stored logs in XML format are already stored in UTF-8.

[svenstorp]

I have pushed initial multi-language support now, with a translation to the world language Swedish. There is a quick tutorial on how to add another language at https://github.com/openambitproject/openambit/wiki/Translations

[bubulle]

Quoting Emil Ljungdahl ([email protected]):

I have pushed initial multi-language support now, with a translation to the world language Swedish. There is a quick tutorial on how to add another language at https://github.com/openambitproject/openambit/wiki/Translations

---

Reply to this email directly or view it on GitHub:
#63 (comment)

Here's a French translation file.

[svenstorp]

Sorry, but I don't think the attached(?) file made it through github.

[marguslt]

AFAIK attachments are ignored when you replay to github issue with e-mail.
Guess it's better just fork - translate - make pull request, maybe add short How To Contribute section to translation wiki page?

[bubulle]

Quoting Emil Ljungdahl ([email protected]):

Sorry, but I don't think the attached(?) file made it through github.

Sent by private mail to Emil....

[paddy-hack]

I've just pushed a couple of changesets that turn all device info strings into null-terminated UTF-8 strings in libambit. The Qt GUI has been updated to follow suit. Next on my list is addressing #70.

[paddy-hack]

I've just pushed a changeset (22a545f) that makes the activity_name a UTF-8 encoded string as well.

[paddy-hack]

So we agreed on UTF-8 for libambit and all strings coming in are properly converted. We have translations for the GUI in several languages and I even added the (horrible?) Dutch (in 4e6f6a6) and Japanese (in 2f0c84a) message catalogs that I mentioned earlier. I'd say this can be closed.