There is code in ZanataUtils that will read an existing zanata.xml,
and parse the details into an instance to support changing an
existing XML file. We have never made use of this functionality,
and it just tripped me up when testing a change for the last time,
destroy it.
Change-Id: Ie3e3ba3d8171ae912f2706dfeb756c007b51b703
When the code was refactored into ZanataRestService, one part
was missed -- namely, _fetch_zanata_xml() in ZanataUtils still
supported a verify argument, but never used it. Remove it.
Change-Id: Id6d39f24bacbf784b2cd230268cdc67ab3fe75fa
Rather than pass verify to each function that requires it, refactor
it down the stack into __init__. Now that we have moved to using
translate.o.o which has a trusted certificate, switch the default
to True.
Add a command-line argument --no-verify to create-zanata-xml to ease
testing against translate-dev.
Change-Id: I0f2314a8e82c3b7f1c96f28408c36ea1dd786e2f
Zanata 3.7.1 moved locale configuration from the client having to
specify them in the zanata.xml file, to having the server make all
the decisions. As such, the server no longer includes any locales
information in the returned configuration.
Change-Id: I2e8870280c30a4b2983996e5e9803933db986add
Using ProjectConfig to talk to the Zanata REST service is rather messy,
and to be frank, a horrible layering voilation. Move it out into its
own class.
Change-Id: I9aee77fe83032a4dfcbdec2f142b9510fef1ab66
We map all locales that contain a _ so that they map correctly to the
locale present on the Zanata server. While testing the pull
functionality, it turns out the client throws a traceback if there are
duplicate locales, so just edit the existing locale element, rather
than adding potential duplicates.
Change-Id: I9fc8df1996a5229bfef8e35f6d2fe62b06f6d01a
For projects such as Manuals and Horizon, the source directory in
zanata.xml is set to '.', which may have the unintended side-effect
of the Zanata client finding .po or .pot files under dot directories.
Add a new option to create-zanata-xml, and use it for those two
projects.
Change-Id: I5fc26069c288eca130a45c6e9c5e3dd00ad2c784
ZanataUtils is a Python module, calling sys.exit() inside it is pretty
bad form, so stop doing it, and move the exit to create-zanata-xml.py.
Change-Id: I0662a5155ff31d37fd7a29e4d024d7279b17ff84
Building on work landed in II3bfb188c8b0c0e65f22d7edc30721b163f084fff,
add support for pushing source documents of Horizon into Zanata.
This has also necessitated adding support for parsing and adding
rules for create-zanata-xml.py.
As a drive-by correct some incorrect docstrings in ZanataUtils, split
some ludicrously long lines calling create-zanata-xml.py, and correct
usage of an undefined variable in setup_django_openstack_auth.
Change-Id: Id7a2c82e979d1f878022b4982f51ef4ef06ecf4b
In order to migrate to Zanata for translations, we need to modify
the proposal scripts to also upload translations to the Zanata
server. This commit supports most projects (those that make use of
upstream_translation_update.sh), as well as django_openstack_auth.
This does not impact the existing push and pull of
translations to Transifex, and also untouched are the translations
for Horizon or the manuals, which are all handled in separate scripts.
Co-Authored-By: stephane <stephane@alum.mit.edu>
Change-Id: I3bfb188c8b0c0e65f22d7edc30721b163f084fff