[Freeipa-devel] Reviving FreeIPA translations

Thu May 26 14:27:44 UTC 2016


On 26.05.2016 16:21, Martin Basti wrote:
>
>
> 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 found in different view, that other branches has been updated too, so 
current sources in zanata should be OK

Martin^2

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