[Freeipa-devel] Reviving FreeIPA translations

Thu May 26 13:51:47 UTC 2016

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 <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
>

Hello all,

I pushed sources to zanata (it seems that nothing changed, because we 
didn't touch user side of freeIPA too much yet)

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
* weekly, month before major release
* daily, week before major release
?

Martin^2