[Freeipa-devel] Reviving FreeIPA translations

Thu May 26 14:21:16 UTC 2016

On 26.05.2016 16:15, Yuri Chornoivan wrote:
> написане Thu, 26 May 2016 16:51:47 +0300, Martin Basti 
> <mbasti at redhat.com>:
>
>>
>>
>> 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)
>
> 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
>> ?
>>
>>
>> Martin^2
>
> Best regards,
> Yuri