Board index FlightGear Development Canvas

Canvas GUI: Internationalization (PM response)

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Canvas GUI: Internationalization (PM response)

Postby Hooray » Sun Nov 23, 2014 8:01 pm

Responding in public to get more eye balls/people involved:

F-JJTH wrote:I investigated the internationalization problem but did not found any *nice* solution. If you have a solution I would be happy to use it.


We do have $FG_ROOT/Translations obviously - but even that doesn't cover GUI dialogs, as per: Issue #263 ("Language option broken")

So, absent a proper solution, the easiest method would be to avoid hard-coding any strings in your widgets/GUI dialogs and using a hash instead as a lookup map, i.e. one that contains keys/values with a sprintf-style format string:

Code: Select all
var myStrings  = {

DEFAULT: {
 WELCOME: "Welcome %s",
 GOODYBE: "Goodbye !",
}, # default (English)

SPANISH: {
 WELCOME: "Hola %s",
 GOODYBE: "Adios !",

}, # Spanish

};



Your GUI dialogs/widgets, would then simply use the corresponding lookup key, e.g.:
Code: Select all
var LANGUAGE='DEFAULT';
var message = myStrings[ LANGUAGE ].WELCOME;


Note that both, Nasal & Canvas do support utf-8, so this should be much more flexible than our existing GUI.
However, it would make sense to introduce a separate Nasal/Canvas module (file) for this, to keep all similar functionality in a single place.

Using this approach, you would never have to touch any GUI dialogs/widgets for updating language support - i.e., you could even maintain those hashes in corresponding *.local files and include those via io.include()
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas GUI: Internationalization (PM response)

Postby elgaton » Sun Nov 23, 2014 9:30 pm

The approach is good, but I think it would be better to use a commonly recognized format for the translation files - this way, should the project use a translation platform (such as Transifex) in the future, it would be easier to directly upload and use those files. (Of course, there should be a Nasal function that reads those files and, given the key, returns the translated string).
NIATCA 2nd admin, regular ATC at LIPX and creator of the LIPX custom scenery
elgaton
 
Posts: 1107
Joined: Tue Mar 19, 2013 4:58 pm
Callsign: I-ELGA/LIPX_TW
Version: Git
OS: Windows + Arch Linux

Re: Canvas GUI: Internationalization (PM response)

Postby Hooray » Sun Nov 23, 2014 9:58 pm

right, adopting some kind of cross-platform standard solution would definitely be a good thing - but it would be more work, too :D
I only suggested to use the Nasal-based route in order not to add external dependencies.
If people generally agree that external dependencies/libs are a no-brainer, there are several feasible candidates.
And for FlightGear it would also be great if web-based translations could be contributed easily.
Until people can come up with some kind of consensus, I'd suggest to use the hash-based method - updating existing Canvas dialogs accordingly should be easy enough, and if/when some standardized method should be adopted, the hash-based approach can be easily ported.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest