написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek <mko...@redhat.com>:
On 05/14/2016 01:29 PM, Yuri Chornoivan wrote:
написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal
2016-05-13 13:32 GMT+02:00 Martin Kosek <mko...@redhat.com>:
As you may or may not know, Tomas Babej left the FreeIPA team as a
employee, which of course does not mean he cannot contribute to the
project, but that he won't have as much time for contributions as
One of Tomas' responsibilities was taking care of FreeIPA translations
(Translation Maintainer role). As far as I know, there 2 main tasks
with the Translation Maintainer role:
1) Periodically uploading new upstream strings to the FreeIPA
platform of choice, which is the Fedora Zanata instance:
The upload should happen periodically, on the right occasions, so
translators (especially the French and Ukrainian translations which
translated) have sufficient time to translate strings for the next
do not have to translate it all in couple days before release. (This
the feedback I heard recently).
2) Downloading translated strings, Tomas added a short HowTo to our
We will need a new volunteer who would help doing 1) and 2) for the
releases and making sure this process runs. The first task would be
current strings in master as the next release is FreeIPA 4.4 planned
so it may be nice to already upload new strings we have in FreeIPA
Zanata, so that they can be translated in sufficient time.
As part of the learning process, I think it would be useful to do more
documentation of the steps taken in every translation life-cycle,
in Release page is rather vague. I for example did not find
work with translation versions that I saw defined in Zanata
similarly as in current FreeIPA git).
Thanks to the two volunteers!
Looking forward to see this happen!
To reiterate on Martin K. message on uploads, I'd really like to see
regular strings uploads to the master branch in Zanata, say once a
every two weeks, so that translators can work on smaller strings
"Release early, release oftem" :)
And strings that would be translated twice in a short time span
entirely lost because they may stay in the Zanata translation memory
could help translators finalizing dot releases if the specific
And if we can see the upload to master soon, translators can start
working now before the branch for the 4.4 June release.
Similar thoughts here.
Thanks for feedback!
Just a note on branches, I think that it is worth to keep the
for the current release because keeping several branches on Zanata (or
other translation platform) is proved to be not effective from both
developers and translators.
I see. My expectation would be that these branches would be only used if
is a bug in the translation, not for active translation. The thing is,
in master may change or may be deleted, so they may no longer be applied
branched FreeIPA x.y.z releases. So practically, we would not be able to
the translations for branched release once we branch.
Do you see that expected and acceptable?
Just two examples from the projects that I am involved (three polar
KDE (Desktop environment):
1. Developed translation infrastructure (dedicated server,
specifically-tailored software (Lokalize)).
2. Four translation branches (stable and trunk for Qt4 and Qt5-based
3. Automatic message extraction every 24 hours.
4. Inbuild translation integration for releases.
All this needs attention and strict release rules to keep everything in
Inkscape (SVG editor):
1. No specific infrastructure.
2. Translation branches are not strict (translators should guess what and
where they are translating).
3. Manual extraction from time to time.
4. No specific integration or QA.
Medium attention paid from the Inkscape developers.
GnuPG (encryption framework):
1. No specific infrastructure.
2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be performed
by translators manually).
3. Manual extraction. No strict release schedule. You are lucky if you
send your translation in time.
4. Manual integration by Werner when he finds it necessary. ;)
Minimum attention paid from the developer.
I think that FreeIPA in the sense of translation handling should be
something in between. For not wasting efforts of the developers (it is
sensible, because of too few more or less complete translations), I
propose to have just one branch (no switching, no problem of choice), but
use it strictly when releasing.
It is better to have a translation with several untranslated new messages
in a branch, than have no update at all because of the release flaws (like
it is in libvirt now). So it would be a good trade off for me if FreeIPA
developers promise to integrate translations into each release, but do not
promise to waste their time for having translation branches. ;)
It is a matter of just two commands (one for extraction and "zanata
pushing the catalog to Zanata). So, personally, I'd like to see the
soon as possible (something close to continuous integration). This
translators, to react on any glitches in the initial strings and make
I think this can be done, there is just the risk that some strings would
added during master development and changed later when the code is
but I assume this is expected by you - correct?
Yes, that's the common translators risk. But we have an automated
translation memory for this. ;)
It would be good if each release preparation process is close to the
Just my 2 cents.
Thanks for the tip!
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code