[Freeipa-devel] Reviving FreeIPA translations

Mon May 16 06:37:27 UTC 2016

On 05/15/2016 09:34 PM, Yuri Chornoivan wrote:
> написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek <mkosek at redhat.com>:
> 
>> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote:
>>> написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal <jfenal at gmail.com>:
>>>
>>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek <mkosek at redhat.com>:
>>>>
>>>>> Hello,
>>>>>
>>>>> 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
>>>>> previously.
>>>>>
>>>>> One of Tomas' responsibilities was taking care of FreeIPA translations
>>>>> (Translation Maintainer role). As far as I know, there 2 main tasks
>>>>> associated
>>>>> with the Translation Maintainer role:
>>>>>
>>>>> 1) Periodically uploading new upstream strings to the FreeIPA translation
>>>>> platform of choice, which is the Fedora Zanata instance:
>>>>> https://fedora.zanata.org/project/view/freeipa
>>>>> The upload should happen periodically, on the right occasions, so that the
>>>>> translators (especially the French and Ukrainian translations which have
>>>>> 100%
>>>>> translated) have sufficient time to translate strings for the next version
>>>>> and
>>>>> do not have to translate it all in couple days before release. (This was
>>>>> one of
>>>>> the feedback I heard recently).
>>>>>
>>>>> 2) Downloading translated strings, Tomas added a short HowTo to our
>>>>> Release page:
>>>>> http://www.freeipa.org/page/Release#Translations
>>>>>
>>>>> 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 would be
>>>>> uploading
>>>>> current strings in master as the next release is FreeIPA 4.4 planned for
>>>>> June,
>>>>> so it may be nice to already upload new strings we have in FreeIPA already
>>>>> to
>>>>> Zanata, so that they can be translated in sufficient time.
>>>>>
>>>>> Volunteer(s)?
>>>>>
>>>>> 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, current
>>>>> HowTo
>>>>> in Release page is rather vague. I for example did not find information
>>>>> how to
>>>>> work with translation versions that I saw defined in Zanata (branching may
>>>>> work
>>>>> 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 week or
>>>> every two weeks, so that translators can work on smaller strings batches.
>>>> "Release early, release oftem" :)
>>>>
>>>> And strings that would be translated twice in a short time span wouldn't be
>>>> entirely lost because they may stay in the Zanata translation memory and
>>>> could help translators finalizing dot releases if the specific branches in
>>>> Zanata.
>>>>
>>>> And if we can see the upload to master soon, translators can start
>>>> working now before the branch for the 4.4 June release.
>>>>
>>>> Regards,
>>>>
>>>> J.
>>>
>>> Hi,
>>>
>>> Similar thoughts here.
>>
>> Thanks for feedback!
>>
>>> Just a note on branches, I think that it is worth to keep the translation just
>>> for the current release because keeping several branches on Zanata (or any
>>> other translation platform) is proved to be not effective from both sides,
>>> developers and translators.
>>
>> 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
>> 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 examples).
> 
> 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
> applications).
> 
> 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 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.

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 doing the
versions if we do not see a need for it.

As for automated message upload, I guess it could be done, we would just need
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 developers
> promise to integrate translations into each release, but do not promise to
> waste their time for having translation branches. ;)

Translations should indeed be integrated in the release process. I would let
the 2 volunteers to update the Release page with the proper process and
instructions :-)

>> It is a matter of just two commands (one for extraction and "zanata
>>> push" for
>>> 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 make the
>>> releases perfect.
>>
>> 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 is revisited,
>> 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. ;)

Ok.

>>> It would be good if each release preparation process is close to the
>>> libguestfs's one:
>>>
>>> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release
>>>
>>> Just my 2 cents.
>>
>> Thanks for the tip!
>>
>> Martin
> 
> Best regards,
> Yuri

Thanks!
Martin