Hi Translators,
during discussion on the FLOCK it has been realized we have some issue with Software String Freeze milestone. The issue is caused mostly by changing some key milestones as a consequence of "No More Alphas" Change [1].
In the past the Software String Freeze milestone was tight together with Alpha Freeze. After we implemented the "No More Alphas" Change [1] and we moved Branching closer to Beta Freeze, we are now in the situation when we need to come up with some conclusion how to plan the Software String Freeze milestone. AFAIK there are two requirements this milestone should fulfil:
* The milestone needs to be planned after Branching * There should be enough time for translators to do the job before Software Translation Deadline (which is currently planned two weeks before Beta Freeze)
Having the Branching 3 weeks before Beta Freeze does not give enough room for translations (comparing to the state before implementation of "No More Alphas" Change [1]). What I see as a possibility now is to have the Software String Freeze milestone one week after Branching and move Software Translation Deadline to the same date as Beta Freeze. This gives us the maximum time period between the "Software String Freeze" and "Translation deadline" we can currently have (even it is just two weeks).
What do you think ? Will such a timing works for these two milestones ( Software String Freeze & Software Translation Deadline ) ? Or anyone have a better proposal ?
[1] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
Thanks for any feedback, Jan
Le 1 septembre 2017 11:45:33 UTC-04:00, Jan Kurik jkurik@redhat.com a écrit :
Hi Translators, "No More Alphas" Change [1]). What I see as a possibility now is to have the Software String Freeze milestone one week after Branching and move Software Translation Deadline to the same date as Beta Freeze. This gives us the maximum time period between the "Software String Freeze" and "Translation deadline" we can currently have (even it is just two weeks).
What do you think ? Will such a timing works for these two milestones ( Software String Freeze & Software Translation Deadline ) ? Or anyone have a better proposal ?
[1] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
Thanks for any feedback, Jan
Hi Jan,
the translation we provides will go to packages and to reach users, it will require a new package release.
Will packagers be able to do so after beta freeze?
Can we also takes the opportunity to clarify what packages are subject to this schedule? I understand that at least every project using the Fedora translation platform are asked to respect this?
Have a nice day, and thank you for your help on this subject!
On Sat, Sep 2, 2017 at 8:55 AM, Jean-Baptiste Holcroft jean-baptiste@holcroft.fr wrote:
Le 1 septembre 2017 11:45:33 UTC-04:00, Jan Kurik jkurik@redhat.com a écrit :
Hi Translators, "No More Alphas" Change [1]). What I see as a possibility now is to have the Software String Freeze milestone one week after Branching and move Software Translation Deadline to the same date as Beta Freeze. This gives us the maximum time period between the "Software String Freeze" and "Translation deadline" we can currently have (even it is just two weeks).
What do you think ? Will such a timing works for these two milestones ( Software String Freeze & Software Translation Deadline ) ? Or anyone have a better proposal ?
[1] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
Thanks for any feedback, Jan
Hi Jan,
the translation we provides will go to packages and to reach users, it will require a new package release.
Will packagers be able to do so after beta freeze?
Can we also takes the opportunity to clarify what packages are subject to this schedule? I understand that at least every project using the Fedora translation platform are asked to respect this?
Have a nice day, and thank you for your help on this subject!
Hi Jean-Baptiste,
as far as I understand the whole Translation process there is still room between Beta and Final freezes to change strings in packages. From the maintainer/packager point of view, the changes in strings should be minimal as during the Beta and Final freezes there are mostly bug fixes, so these changes should not affect translated strings in most cases. From the translation point of view, the period between Beta and Final freezes can be used for bug fixes in translated strings.
As far as I understand the scope of translation we (as Fedora community) provide, the String Freeze should apply only to packages in Zanata. Projects which are not translated by our (Fedora) community might have independent cycle and the String Freeze does not apply on these.
Hopefully someone more senior in this area might answer these questions, if I am wrong :-)
Thanks for your replay and Best Regards, Jan
2017-09-02 15:29 GMT+02:00 Jan Kurik jkurik@redhat.com:
As far as I understand the scope of translation we (as Fedora community) provide, the String Freeze should apply only to packages in Zanata. Projects which are not translated by our (Fedora) community might have independent cycle and the String Freeze does not apply on these.
Hopefully someone more senior in this area might answer these questions, if I am wrong :-)
In theory, the string freeze is about projects in the “main” group, as opposed to the “upstream” group:
https://fedora.zanata.org/version-group/list
In practice, we have no way to enforce it and we rely exclusively on good will of the developers.
Best regards,
2.09.2017 16:56 Piotr Drąg piotrdrag@gmail.com wrote:
2017-09-02 15:29 GMT+02:00 Jan Kurik jkurik@redhat.com:
As far as I understand the scope of translation we (as Fedora community) provide, the String Freeze should apply only to packages in Zanata. Projects which are not translated by our (Fedora) community might have independent cycle and the String Freeze does not apply on these.
Hopefully someone more senior in this area might answer these questions, if I am wrong :-)
In theory, the string freeze is about projects in the “main” group, as opposed to the “upstream” group:
https://fedora.zanata.org/version-group/list
In practice, we have no way to enforce it and we rely exclusively on good will of the developers.
True, this does not apply to the projects where Fedora only pulls whatever source code is released by upstreams, including translations already, and rebuilds and packages it.
But even if a translation of a project is hosted in Zanata we have no power to enforce their release cycle. Therefore I think we should change the perspective and instead of talking about projects translated in Zanata we should talk about projects where Fedora acts as an upstream as well. That means, the projects hosted at pagure.io. While eventually "being hosted at pagure.io" should mean the same as "being translated in Zanata". That means that projects are encouraged to be both translated in Zanata and hosted at pagure.io. But as long as exceptions exist we must accept that some projects will want to be translated in Zanata but will not follow our release cycle. We are encouraging other projects to join Zanata but we are not telling them "OK, you agreed so now you must follow our release cycle" or "either you decide to follow or you are removed from Zanata". If the projects don't follow the release cycle the consequence is that their translations may be incomplete or delayed and then it's their problem if they accept it or not, also it's our problem if we as packagers accept the upstream source code with some l10n issues.
Shortly, my point is that if we change perspective from Zanata to pagure.io it defines the area where we have power to control the upstream release cycle because we are the upstream.
Regards,
Rafal
Le 2 septembre 2017 20:35:49 UTC, Rafal Luzynski digitalfreak@lingonborough.com a écrit :
Therefore I think we should change the perspective and instead of talking about projects translated in Zanata we should talk about projects where Fedora acts as an upstream as well. That means, the projects hosted at pagure.io. While eventually "being hosted at pagure.io" should mean the same as "being translated in Zanata". That means that projects are encouraged to be both translated in Zanata and hosted at pagure.io. But as long
Ease the path to Zanata for project hosted on pagure is a good idea, but enforcing it is not possible and probably not a good idea.
I would rather improve the communication about what's "main" and select them with the Fedora community approval. At the moment, as far as I know, this group is own by Translators and should be managed with other groups.
We should make sure key projects (for user experience) are being friendly regarding to our release process, whatever they are tight to our release cycle or not. This means communication and enrolment. I'm sure will get council support for this, as far as our process is correctly explained.
Thank you for all the feedback. The conclusion I made from this email thread for planning of the String Freeze milestone is to proceed with the proposal I made at the beginning:
* Software String Freeze milestone is going to be planned one week after Branching * Software Translation Deadline is going to be planned to the same date as Beta Freeze
Lets start with this for F28 release and we will see whether it works or not. We can always change it, if needed.
Regards, Jan
On Sun, Sep 3, 2017 at 2:17 AM, Jean-Baptiste Holcroft jean-baptiste@holcroft.fr wrote:
Le 2 septembre 2017 20:35:49 UTC, Rafal Luzynski digitalfreak@lingonborough.com a écrit :
Therefore I think we should change the perspective and instead of talking about projects translated in Zanata we should talk about projects where Fedora acts as an upstream as well. That means, the projects hosted at pagure.io. While eventually "being hosted at pagure.io" should mean the same as "being translated in Zanata". That means that projects are encouraged to be both translated in Zanata and hosted at pagure.io. But as long
Ease the path to Zanata for project hosted on pagure is a good idea, but enforcing it is not possible and probably not a good idea.
I would rather improve the communication about what's "main" and select them with the Fedora community approval. At the moment, as far as I know, this group is own by Translators and should be managed with other groups.
We should make sure key projects (for user experience) are being friendly regarding to our release process, whatever they are tight to our release cycle or not. This means communication and enrolment. I'm sure will get council support for this, as far as our process is correctly explained.
Jean-Baptiste Holcroft _______________________________________________ trans mailing list -- trans@lists.fedoraproject.org To unsubscribe send an email to trans-leave@lists.fedoraproject.org