My favorites | Sign in
Project Home Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 263: Language option broken
1 person starred this issue and may be notified of changes. Back to list
Status:  Verified
Owner:  gijsrooy
Closed:  May 2012
Cc:  zakalawe@mac.com
GUI


Sign in to add a comment
 
Project Member Reported by gijsrooy, Jan 27, 2011
What steps will reproduce the problem?
1. Launch FlightGear with an extra command: "--language=nl".

What is the expected output? What do you see instead?
The in-sim menu should be translated in Dutch (at least most of the options; those that existed when the translation was written).

Running "fgfs --help --verbose" does show the translated options, so that part works.

What version (or GIT date / Hudson build number)?
Today's Git, confirmed by various people on IRC.

What operating system?
Windows Vista, but also other systems.
May 19, 2011
Project Member #1 bre...@gmail.com
(No comment was entered for this change.)
Labels: Priority-Medium
Jul 7, 2011
Project Member #2 cumuluni...@gmail.com
 Issue 365  has been merged into this issue.
Apr 18, 2012
Project Member #3 gijsrooy
fgfs --help --verbose --language=nl 

neither seems to give the translated help anymore...
Apr 18, 2012
Project Member #4 bre...@gmail.com
The language option is broken altogether now. Also switching the language for the command-line help no longer works. Reason is "--help" is evalauted very early now, while all the other options (including "--language") are deferred and only evaulated during the "normal" fgfs session start-up. Obviously, "--language" also needs to be evaluated early - so it can influence the "--help" ouput.

@zakalawe: Could you have a look at fixing/changing the new option parser?
Cc: zakalawe@mac.com
Apr 18, 2012
Project Member #5 zakalawe@mac.com
Fixed for --help in https://gitorious.org/fg/flightgear/commit/516d92c077271e7e2fc22f9a7e4c15adb67f5d29

The main issue is still broken, I'm not sure what is required to fix that.
Apr 18, 2012
#6 wonco...@googlemail.com
The initial report says that the GUI is supposed to be translated (to Dutch), I don't fully understand how this is supposed to work: 

The translations in $FG_ROOT/Translations are specifically written such that all the translations are conventional PropertyList files which are written to the "strings" branch in the property tree, so that the "CLI help" can explicitly resolve them by getting all strings via fgGetStringValue() after setting the locale properly. 

However, translating the *GUI* is a different beast and simply cannot work like this: The GUI PropertyList XML files (including the menubar and ALL dialogs) are written such that they directly reference the plain ASCII strings to be used by PUI, there's no layer of indirection here using "proxy properties".

According to the files in $FG_ROOT/Translations, they must obviously be loaded AFTER menubar.xml and AFTER other GUI files, in order for the translation markup to be able to overwrite the defaults specified in the corresponding menubar/dialog XML file.

So it seems, what's really needed is modifying the loader for the menubar and for GUI dialogs, so that they AUTOMATICALLY reload $FG_ROOT/Translations/strings-LOCALE.xml AFTER loading menubar.xml/dialog.xml. That would take care of any available translations, because it would overwrite the defaults.

Otherwise, I don't see any clean or simple way to reintroduce i18n support without modifying tons of XML files and C++ code to use indirectly referenced strings.
Apr 18, 2012
Project Member #7 zakalawe@mac.com
@woncount, thanks for doing some research on this. I think your description is roughly correct, but that it's possible to do the combining of the Translations properties with the dialogs / menubar a little bit smarter. The crucial point is there's only a couple of places (in dialog.cxx) where label / legend text is looked up, and making them check the active locale first should be easy.

(I hope, I didn't actually double-check the code yet).

Will take a look later, but if you want to propose a patch, that might motivate me too. It would be really nice to get this working again.
Apr 18, 2012
Project Member #8 bre...@gmail.com
It's actually quite easy to enable the language option again (works for me ;-) ). The resources (at least the German resource) even already have translations for some of menu entries - so this was obviously working some time ago. Some new menu options only provide a "label" - not a "name", which is necessary for mapping the menu entries, but that's easy to add.

Main issue I'm having though: the PUI fonts seem incomplete. For German, I really need the "ä", "ö", "ü" to work - likewise more characters are needed for French, Norwegian,... Not sure if I'm having just a character mapping issue, or if these characters are missing altogether. Also, there's probably no Chinese or Japanese PUI font(?). But this might be fixed once PUI is ported to OSG?
Apr 18, 2012
#9 wonco...@googlemail.com
I am not sure if you should literally preload the properties from the locale XML first: 

You would need to explicitly load everything into a temporary property tree, then do a property lookup to see if the corresponding properties exist or not i.e. foo->hasValue() etc - and do that for all sorts of GUI related string properties (names, legends etc).

Yeah, it's obviously possible - but simply reloading the PropertyList XML with the right locale would be much simpler, and shouldn't break anything, right?
In fact, you could keep a copy of the locale around in a temporary SGPropertyNode, created at startup - and then simply apply it shortly before updating the GUI.

I think there are still some potential caveats here, though:

- the menubar is apparently intended to be runtime-modifiable, so that just writing to the property tree and issuing some GUI update/reinit command, causes the changes to take effect: We don't want the locale to override this, and we also don't want the locale to be overridden.

- it would probably make sense to bind a listener to the locale property, so that the locale can be easily switched at runtime - this would certainly also help to spot any related issues in the future (regression-testing wise).


PS: The last patch I provided ended up not being reviewed for several months, and then it got replaced by a much better and much more elegant solution, written by you :-)
So I'm not sure if it makes too much to look into this now. 
Also, speaking from a personal point of view: even if 100% of the GUI were to be translated, you still wouldn't be able to use most of FG without understanding English. English is simply the standard language in aviation - an i18n GUI doesn't change this.
Apr 18, 2012
Project Member #10 bre...@gmail.com
Sorry, but I don't think switching the locale at run-time is valid use case. Too much hassle for very little gain. There's also better ways to test this, than switching at run-time - which just introduces new issues on its own.
Apart from this, the menubar is already well prepared for localization. And simply defining English as "the standard language", doesn't really help anyone.
Apr 18, 2012
Project Member #11 zakalawe@mac.com
Agreed - switching at runtime is very complex, but showing localised UI is useful. Of course the cockpits and aviation terminology will reflect English, but it's really nice for users to at least have the option to localise our UI.

Thorsten, any clue how far we are from having this work for dialogs? As noted above, the places where we pass string values to PUI are extremely narrow, but I don't want to key off the English text in each dialog, so I guess we need to add a name / id to each widget, that can be looked up in the translation file.

(And that allows standard names to be shared between dialogs, e.g. 'apply', 'reset' and 'cancel')
Apr 18, 2012
#12 wonco...@googlemail.com
Looking through the XML dialogs and the C++ code, the most flexible option would probably be supporting an XPATH expression in the locale XML, so that names/labels/legends can be replaced.

Like you say, for certain strings ('okay','reset','cancel','apply','load','save') this could be done automatically, if a corresponding localized string is available.

On the other hand, there's also a fair share of dynamic dialogs created using Nasal or even Nasal embedded in XML files (e.g. replay.xml) - so this needs to take place fairly late, when building the PUI dialog, i.e. somewhere in FGPUIDialog::setupObject (puObject *object, SGPropertyNode *props)?

Also, there are obviously generic/shared strings, which could and should be reused by most dialogs, and dialog-specific strings, which probably don't belong into the same "global" string pool. Otherwise, there'd probably be a huge XML file with tons of unused strings eventually, just because some dialogs got renamed or removed.

So it would probably make sense to have the global string pool which is shared, for generic strings - and simply include dialog-specific strings within the XML dialog itself?

By convention, one could then move dialog-specific strings to the global string pool once they're used by more than a single dialog.

May 16, 2012
Project Member #13 gijsrooy
Fixed now, thanks Thorsten!
Status: Verified
Labels: Milestone-2.8.0
May 29, 2012
#14 rolanddu...@gmail.com
French translation added as merge request today. Translation will alter only command line options + main menus, not submenus. Would be glad to help translating the rest of the UI.
May 29, 2012
Project Member #15 gijsrooy
Thanks Roland, pushed!

Dialog translations are not (yet) supported...
Sign in to add a comment

Powered by Google Project Hosting