Re: [Freeipa-devel] Reviving FreeIPA translations
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 : 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 : On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : 2016-05-13 13:32 GMT+02:00 Martin Kosek : 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 eff
Re: [Freeipa-devel] Reviving FreeIPA translations
On 26.05.2016 16:15, Yuri Chornoivan wrote: написане Thu, 26 May 2016 16:51:47 +0300, Martin Basti : 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 : On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : 2016-05-13 13:32 GMT+02:00 Martin Kosek : 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, bec
Re: [Freeipa-devel] Reviving FreeIPA translations
написане Thu, 26 May 2016 16:51:47 +0300, Martin Basti : 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 : On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : 2016-05-13 13:32 GMT+02:00 Martin Kosek : 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 mor
Re: [Freeipa-devel] Reviving FreeIPA translations
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 : On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : 2016-05-13 13:32 GMT+02:00 Martin Kosek : 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
Re: [Freeipa-devel] Reviving FreeIPA translations
On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: > написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek : > >> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>> написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : >>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : > 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 extra
Re: [Freeipa-devel] Reviving FreeIPA translations
написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek : On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : 2016-05-13 13:32 GMT+02:00 Martin Kosek : 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.
Re: [Freeipa-devel] Reviving FreeIPA translations
2016-05-15 20:51 GMT+02:00 Martin Kosek : > On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: > > написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal >: > > > >> 2016-05-13 13:32 GMT+02:00 Martin Kosek : > >> > >>> 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? > Fine by me. Maybe we could add a note to the wiki that older branches present in Zanata shouldn't be actively translated, and present only for bugfixing. > > 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? > It is indeed. And desirable. The closer we can be from development, the better it is for quality as Yuri explained it: translators do read the English source strings ;). > > 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 >
Re: [Freeipa-devel] Reviving FreeIPA translations
On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: > написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : > >> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >> >>> 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? > 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? > 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 -- 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
Re: [Freeipa-devel] Reviving FreeIPA translations
написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal : 2016-05-13 13:32 GMT+02:00 Martin Kosek : 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. 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. 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. 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. Best regards, Yuri -- 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
Re: [Freeipa-devel] Reviving FreeIPA translations
2016-05-13 13:32 GMT+02:00 Martin Kosek : > 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. -- Jérôme Fenal -- 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
Re: [Freeipa-devel] Reviving FreeIPA translations
On 05/13/2016 01:32 PM, Martin Kosek wrote: 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). I also volunteer for the job. -- Martin^3 Babinsky -- 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
Re: [Freeipa-devel] Reviving FreeIPA translations
On 13.05.2016 13:32, Martin Kosek wrote: 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). I volunteer Martin^2 -- 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
[Freeipa-devel] Reviving FreeIPA translations
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). -- Martin Kosek Manager, Software Engineering - Identity Management Team Red Hat, Inc. -- 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
