I'm not quite sure, but it seems to me that Qt Linguist treats the
Turkish language as having one "universal form". We need plural forms
for Turkish since FGData commit c0bb8d8a8d64e1 in branch
'release/2020.3' added a 'tr' translation.
- Move test_catalog.py, test_sgprops.py and catalog/testData/ to
python3-flightgear/flightgear/meta/tests/.
- Copy catalog/fgaddon-catalog/ to the same place (it is needed by
test_catalog.py).
- Adapt test_catalog.py and test_sgprops.py accordingly.
- Remove the executable bits from test_catalog.py and test_sgprops.py:
this is because test_catalog.py can't be run directly anymore; well,
it can but 3 tests would fail in this setup. No time to investigate
why (sorry), but this commit adds a README.txt in
python3-flightgear/flightgear/meta/tests/README.txt that explains how
to run the tests in a way that works (basically, run
'python3 -m unittest' from the python3-flightgear directory).
For a bit more context, see
<https://sourceforge.net/p/flightgear/mailman/message/37042247/>.
Also add a README.md to python3-flightgear explaining how to use the
PYTHONPATH environment variable or a .pth file in order to run the
Python scripts in FGMeta, and pointing to the top-level directories
'catalog' and 'i18n'.
- Move the support modules inside python3-flightgear/flightgear/ and
remove their shebang, if any.
- Accordingly adapt the import statements.
- Change shebangs from e.g. '#! /usr/bin/python' to
'#! /usr/bin/env python3'.
- Small changes to make Python 3 happy with all scripts.
catalog/check_aircraft.py should be run under Python 3 from now on.
- Use the new flightgear.meta.strutils.simplify() function.
- Automatically add a comment to the generated file to indicate that it
was automatically generated and shouldn't be manually modified, etc.
- Improve error handling: abort with a clear error message if any of the
'id', 'name' and 'desc' children of a 'scenario' element is
problematic (empty or missing, for instance).
- Rename make_xml_leaf() to makeXmlLeaf() + other minor renaming.
I believe the problematic code could only be reached when reading buggy
versions (i.e., with duplicate ids) of the legacy FlightGear XML
non-master l10n files, which is why we haven't tripped on it so far.
Introduce a BASIC_CATEGORIES variable at the top of
python3-flightgear/flightgear/meta/i18n.py that lists all categories
handled by BasicL10NResourceManager. Since currently all of our
translation files can be handled this way (the XML master files all have
a flat structure), we only need to say BASIC_CATEGORIES = CATEGORIES.
With this change, adding a new basic category such as
'weather-scenarios' only requires one to add it to CATEGORIES.
- Add class method availableTranslations() to AbstractFormatHandler in
i18n.py.
- Use it in fg-update-translation-files to allow autodetection of the
available translations when no LANGUAGE_CODE is passed to
fg-update-translation-files.
This should address James' wish at
<https://sourceforge.net/p/flightgear/mailman/message/37003967/>.
This class isn't needed anymore now that
$FG_ROOT/Translations/default/sys.xml has a flat structure, like the
other FG XML i18n files that define the default translation. This is
related to
6d6e1809f0/
and more specifically to
587c601345/
Translation.__setitem__() from flightgear/meta/i18n.py isn't used
anywhere here (it is not very useful), so no harm done, but that could
have confused potential readers.
This script is designed for the following use case:
Suppose a translator has been working on a particular translation file,
and meanwhile the official XLIFF file for this translation has been
updated in FGData (new translatable strings added, obsolete strings
marked or removed, etc.). In such a case, 'fg-merge-xliff-into-xliff'
can be used to merge the translator's work into the official XLIFF
translation file. Essentially, this means that for all strings that have
the same source text, plural status, number of plural forms and of
course target language, the target texts, "approved" status and
translator comments will be taken from the first file passed in the
following command:
fg-merge-xliff-into-xliff TRANSLATOR_FILE PROJECT_FILE
Used like this, PROJECT_FILE will be updated with data from
TRANSLATOR_FILE. If you don't want to modify PROJECT_FILE, use the -o
(--output) option. If '-' is passed as argument to this option, then the
result is written to the standard output.
- Remove unnecessary imports
These imports were a leftover from early versions; now, they are done
in modules such as flightgear.meta.i18n and don't need to be in the
calling scripts anymore.
- Fix an exception message
This is a simple Python 3 script to ease rebuilding of FGData embedded
resources for FlightGear. It uses fgrcc in conjunction with
<FlightGear-repo>/src/EmbeddedResources/FGData-resources.xml and the
FGData files mentioned therein to (re)create the FGData-resources.[ch]xx
files used in the FlightGear build. The existing files in the FlightGear
repository are always overwritten (namely, FGData-resources.[ch]xx in
<FlightGear-repo>/src/EmbeddedResources).
There are command-line options (--flightgear, --fgdata and --fgrcc) to
indicate where the FlightGear and FGData repositories, as well as the
fgrcc executable can be found. However, it is most convenient to put
these paths once for all in the config file
$HOME/.fgmeta/rebuild-fgdata-embedded-resources.json (use
'rebuild-fgdata-embedded-resources --help' to see an example). This way,
you can invoke the script without any argument whenever you want to
update <FlightGear-repo>/src/EmbeddedResources/FGData-resources.[ch]xx.
This script doesn't depend on any module out of the Python standard
library (intentionally, in case distributors want to use it to recreate
themselves the FGData-resources.[ch]xx files). It should work on Python
3.5 and later versions.
Add the following files:
python3-flightgear/README-l10n.txt
python3-flightgear/fg-convert-translation-files
python3-flightgear/fg-new-translations
python3-flightgear/fg-update-translation-files
python3-flightgear/flightgear/__init__.py
python3-flightgear/flightgear/meta/__init__.py
python3-flightgear/flightgear/meta/exceptions.py
python3-flightgear/flightgear/meta/i18n.py
python3-flightgear/flightgear/meta/logging.py
python3-flightgear/flightgear/meta/misc.py
They should work on Python 3.4 and later (tested with 3.5.3). The folder
structure is chosen so that other FG support modules can insert
themselves here, and possibly be used together. I put all of these
inside 'flightgear.meta', because I don't expect them to be needed at FG
runtime (neither now nor in the future), probably not even by the CMake
build system.
To declare that a string has plural forms, simply set the attribute
'with-plural' to 'true' on the corresponding element of the default
translation (and as in Qt, use %n as a placeholder for the number that
determines which singular or plural form to use).
