On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: > написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek <mko...@redhat.com>: > >> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>> написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal <jfe...@gmail.com>: >>> >>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek <mko...@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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code