Post by James Turner
I need to finish off the keybinding + action changes and will look at
translations immediately afterwards.
Thank you. No need to hurry up, soon you'll be either waiting for me or
doing the missing stuff yourself...
I've pushed a change this morning (still in
- Most of the code is now available as a library (Python modules inside
the flightgear.meta Python package. It might be a good idea in the
future to lay out all the Python 3 FG meta code using a similar
structure: this would make it possible to use all the available Python
code together if needed: this l10n stuff, PropertyList files parsing,
- More OOP to allow clean extensibility, in particular to deal with
FlightGear XML localization files that have different structures
depending on the category. This was already needed, but so trivial
(sys.xml having everything inside a <splash> element) that a simple
hack did the job. The current structure makes this cleaner: for each
category that needs different parsing rules, one can define a subclass
of flightgear.meta.i18n.L10NResourceManagerBase that knows how to
parse resource files of said category. This will allow one to have,
e.g., fr/dialogs.xml with a structure like this:
<?xml version="1.0" encoding="UTF-8" ?>
<label>Rendu de la lumière du soleil</label>
<label>Rendu du terrain</label>
<tooltip>Autre bla bla...</tooltip>
I got a request in private about translating dialogs generated from
property tree subtrees, e.g. boolean props that could (?) have 'label'
and 'tooltip' attributes on the respective property nodes to describe
a dialog with checkboxes; by using values such as
dialogs/draw-masks:widgets:render-sunlight:tooltip:0 for such
attributes (see below), the FG C++ code could easily get translations
for said labels and tooltips from a
- The two currently-used structures for FlightGear XML localization
files are handled by the classes
flightgear.meta.i18n.BasicL10NResourceManager (for all categories but
'sys') and flightgear.meta.i18n.SysL10NResourceManager (for 'sys').
- To support this, flightgear.meta.i18n.AbstractTranslationUnitId can be
subclassed in order to provide nice Python id objects for translation
units, that contain all the needed metadata to describe where in a
complex hierarchy a given translation unit occurs. For instance, the
above example could lead to XLIFF ids (obtained from the corresponding
Python id objects) such as
dialogs/draw-masks:widgets:render-sunlight:label:0 (:0 being for the
PropertyNode index, as already the case). This will allow C++ code to
look up translated strings in the XLIFF files based on the structure
in the corresponding FlightGear XML localization files (dialogs.xml in
- Output XLIFF <trans-unit> 'id' attributes now look like
menu/aircraft-checklists:0 instead of menu:aircraft-checklists:0
(easier to read with a "deep" structure as in the above example).
Kown-missing bits in this Python part of the infrastructure:
- code to update Translations/<langCode>/<cat>.xml from
* strings in the latter but not in the former must be added with
an empty translation and approved="no" (new strings);
* strings in the former but not in the latter must be marked with
translate="no" (obsolete or vanished in Linguist-speak);
* strings present in both but where the sourceText differs must be
marked with approved="no" (= needs review by translators).
- currently, the produced XLIFF files only contain <trans-unit>
elements for strings that have a translation in the corresponding
Translations/<langCode>/<cat>.xml file. So, it's not possible yet to
finish an incomplete translation. However, all that is needed to fix
this is to apply the code from the previous point, once it's done,
to the translations produced in the current state (and probably all
strings will have to be marked with approved="no", because many are
probably out of sync with the present default translation).
- a command/option or a separate script to produce skeleton XLIFF
files for new languages (trivial: this is the default (= master)
Translation instance with only the targetLanguage and masterTransl
attributes properly set).
If all goes well, I'll add these missing pieces in the next days...