This is mainly to make it clear that the "translation" in (after this
commit) Translations/default, a priori corresponding to en_US, has a
special status: it acts as the source describing the set of translatable
strings, each with its id (an XML tag name) and numeric index (a
PropertyList index, often 0 but not always).
In the upcoming i18n infrastructure, the files in Translations/default
will be used to:
- detect all translatable strings (~ string extraction);
- detect obsolete translated strings (those in XLIFF files but not in
Translations/default anymore);
This will allow a script to update the XLIFF files containing real
translations, i.e., update the source strings and possibly remove
obsolete entries.
So, the files in Translations/default have a special "master" status in
this process, and are technically quite different from those in
Translations/de, Translations/es, Translations/fr, etc. The latter XML
files (those not in Translations/default) will be replaced with their
XLIFF equivalent, by the way (conversion script already working).
See discussion at
<https://sourceforge.net/p/flightgear/mailman/message/35910579/>.
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...
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).
- Needs FlightGear compiled with -DENABLE_PACKAGE_SYSTEM.
- Shows only first 100 available aircrafts.
- Now progress indication on install/remove (need to reopen
dialog afterwards)
Fix the main bugs, add features and convert most of the layers.
Move/refactor some things as well. Add a canvas map dialog next to the
built-in one -- it's not 100% functional but it's quite close actually.
As before, the excitement has been taking place at our team clone.
https://gitorious.org/fg/canvas-hackers-fgdata/commits/0b4cc84
(topics/canvas-map-dialog branch this time, current HEAD in above URL.)
Features:
- Various configurable styles.
- Working scroll bars, thanks to Tom
- Adequate REPL-ness.
See the wiki for more information!
http://wiki.flightgear.org/Interactive_Nasal_Console
N.B. This makes some (sane) changes to other Nasal files, including
expanding some of the Canvas API.
Replace the temporary UI with real solutions, in the view dialog
(for tooltips/popups) and a new 'input config' dialog accessed via
the file menu.
Make the mouse-cycle popup explicitly optional since some people
strongly dislike it.
This is temporary (hopefully!), to allow experimentation with different UX options in the near future. Right now it basically does nothing. As part of this, factor mouse-mode cycling into a separate command, and add some feedback. Feedback mechanism needs work, currently abusing the copilot facility.
such as snow level, dust, wetness, and texture set.
Also add a parameter to control whether the snow level moves with METAR,
and retire /environment/mysnow-level-m.
