On 26.05.2016 16:21, Martin Basti wrote:
I found in different view, that other branches has been updated too, so
current sources in zanata should be OK
On 26.05.2016 16:15, Yuri Chornoivan wrote:
написане Thu, 26 May 2016 16:51:47 +0300, Martin Basti
On 16.05.2016 08:37, Martin Kosek wrote:
On 05/15/2016 09:34 PM, Yuri Chornoivan wrote:
написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek
Thanks for the overview! Based on what I see so far, it looks like
there is not
an interest for the branched translations. So I am fine with not
Just two examples from the projects that I am involved (three
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 Red Hat
employee, which of course does not mean he cannot contribute
to the FreeIPA
project, but that he won't have as much time for contributions as
One of Tomas' responsibilities was taking care of FreeIPA
(Translation Maintainer role). As far as I know, there 2 main
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 that the
translators (especially the French and Ukrainian translations
translated) have sufficient time to translate strings for the
do not have to translate it all in couple days before release.
the feedback I heard recently).
2) Downloading translated strings, Tomas added a short HowTo
We will need a new volunteer who would help doing 1) and 2)
for the planned
releases and making sure this process runs. The first task
current strings in master as the next release is FreeIPA 4.4
so it may be nice to already upload new strings we have in
Zanata, so that they can be translated in sufficient time.
As part of the learning process, I think it would be useful to
documentation of the steps taken in every translation
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
regular strings uploads to the master branch in Zanata, say
once a week or
every two weeks, so that translators can work on smaller
"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
could help translators finalizing dot releases if the specific
And if we can see the upload to master soon, translators can
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 any
other translation platform) is proved to be not effective from
I see. My expectation would be that these branches would be only
used if there
is a bug in the translation, not for active translation. The
thing is, strings
in master may change or may be deleted, so they may no longer be
applied to the
branched FreeIPA x.y.z releases. So practically, we would not be
able to update
developers and translators.
the translations for branched release once we branch.
Do you see that expected and acceptable?
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 sync.
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
3. Manual extraction. No strict release schedule. You are lucky if
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
in between. For not wasting efforts of the developers (it is
of too few more or less complete translations), I propose to have
branch (no switching, no problem of choice), but use it strictly
versions if we do not see a need for it.
As for automated message upload, I guess it could be done, we would
to think if it fits in current Jenkins infrastructure. But I
suspect it could
also be on any cron-powered PaaS, like OpenShift.
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
promise to integrate translations into each release, but do not
Translations should indeed be integrated in the release process. I
the 2 volunteers to update the Release page with the proper process
waste their time for having translation branches. ;)
Yes, that's the common translators risk. But we have an automated
It is a matter of just two commands (one for extraction and "zanata
I think this can be done, there is just the risk that some
strings would be
added during master development and changed later when the code
pushing the catalog to Zanata). So, personally, I'd like to see
the updates as
soon as possible (something close to continuous integration).
This allows us,
translators, to react on any glitches in the initial strings and
but I assume this is expected by you - correct?
memory for this. ;)
It would be good if each release preparation process is close to
Just my 2 cents.
Thanks for the tip!
I pushed sources to zanata (it seems that nothing changed, because
we didn't touch user side of freeIPA too much yet)
Many thanks for your work.
I'm not sure if it works, in history I see that just ipa-4-2 branch
has been updated in zanata, and I tried to push master twice and there
is no information about it in zanata web, I have to investigate more.
I pushed sources to all branches but as we agreed, only master
should be activelly translated, should I lock translations for IPA
4.2 and possibly for 4.3?
Could it work if we push sources to zanata:
* monthly for everything
My vote is for this case.
I meant this as closer to release then more frequent pushes to zanata
* weekly, month before major release
* daily, week before major release
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code