This brings a developer comment to the FlightGear-Qt.xlf files that will
hopefully draw the translators' attention on the fact that they should
put the *up-to-date* address of the "getstart" manual in their language
(use correct address + two occurrences of 'en' to change).
Remove no more used `menu/interface-config`.
Add `menu/highlighting`, `menu/vr-options`, `options/system-time`,
`options/gmt`, `options/local-aircraft-time`.
Correct tip text from "Hold [Shift] while looking around to move the
view up, down, left or right" to "Hold Ctrl ...".
Corrections for Polish nonQt translations.
Apparently, this file hasn't received the cleaned up source strings for
weather scenarios obtained since FGMeta commit c2a241c35[1]. The file
committed here was produced by simply running
fg-update-translation-files with what we currently have in FGData. I've
ignored changes to the other FlightGear-nonQt.xlf files because they
seem to all boil down to a modification of the order in which XML
attributes are given (what a PITA!).
[1] c2a241c357
Update them from the latest contents of the
$FG_ROOT/Translations/default/*.xml files (default translation).
This was done with:
fg-update-translation-files \
--transl-dir="/path/to/fgdata/Translations" \
merge-new-master de en_US es fr it nl pl pt zh_CN
The reason French is treated specially is that I completed the
translation up to 100% coverage in Qt Linguist as a test case for the
new translation infrastructure, and have no desire to convert this
translation work to the legacy FlightGear-specific XML format. But of
course, this complete translation is in XLIFF 1.2 format (since it is
saved by Qt Linguist) and thus can't be used by FlightGear yet.
On the other hand, for the other languages, no translator ever modified
the XLIFF files, therefore the best way to proceed for is that people
continue to work with the legacy FlightGear-specific XML format until
the new translation infrastructure is ready (this way, their work is
visible in FlightGear). The Python-based tools in FGMeta allow one to
automatically convert from this legacy format to the XLIFF 1.2 format,
as explained in fgmeta/python3-flightgear/README-l10n.txt. Which is
precisely what this commit does.
These files have been generated from the existing XML files (cf.
fg-convert-translation-files in fgmeta).
Translations/en_US/FlightGear-nonQt.xlf is for a proper English
translation, where for instance "found %n airport(s)" would have two
plural forms, "found %n airport" and "found %n airports" (most
non-plural strings can be taken verbatim from the default translation,
and at this point there is no plural form at all yet).
It's not that leading or trailing whitespace in translated strings is
forbidden *in principle*, but I think it is unwanted in most of these
cases. Remove these spaces that could cause confusion, possibly useless
work for translators and/or ugly displays.
The only cases where the spaces seem to have been intentional are the
trailing ones in menu labels (Translations/*/menu.xml), in order to
obtain right alignment of keyboard shortcuts. However, there is only one
case in English where the spacing looks approximately correct
(File -> Reset). In all other cases, it looks awful. And this poor way
of obtaining right alignment gives bad results in other languages, where
translators use the same number of spaces as in English.
Bottom line: if right alignment of keyboard shortcuts is indeed desired
in the menu labels (I think it is), it should be done in a smarter
way...
This translated string has been removed from Translations/en/menu.xml in
commit f3ac93b1ef. Remove its translations
from the other Translations/*/menu.xml files that still have it.
This translated string has been removed from Translations/en/menu.xml in
commit ff87cf4257. Remove its translations
from the other Translations/*/menu.xml files that still have it.
Also remove <intl include="Translations/locale.xml"/> from
preferences.xml. Something equivalent based on readProperties() is done
in FlightGear (cf. FGLocale::FGLocale() in
flightgear/src/Main/locale.cxx).
