[Freeipa-devel] Reviving FreeIPA translations

Thu May 26 14:15:10 UTC 2016

написане 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 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.

> * weekly, month before major release
> * daily, week before major release
> ?
>
>
> Martin^2

Best regards,
Yuri