Open Stack

Hello Sean,

For soft string freezes as a translator's view, trying the way you 
suggested for server projects would be good assuming that:
- The volume of changes (e.g., the number of sentences, ratio of 
changes) needs to be properly limited
- The string change needs to be well notified to translators (e.g., 
sharing to openstack-i18n mailing list)
- It would be so nice if I18n team can keep track of original string 
changes in Zanata - translate.openstack.org but
   currently it is not easy unfortunately.

For hard string freezes, in my honest opinion, it is difficult to change 
the current policy
because some translation sync support activities for a stable branch in 
openstack-infra [1] and
addition of a stable version in translate.openstack.org [2] are dealt.

 From those views, I would like to discuss more opinions and would we 
try better approach from the next development cycle
with agreement for server projects?


With many thanks,

/Ian

[1] 
https://review.openstack.org/#/c/435812/1/jenkins/jobs/projects.yaml@1146
[2] https://translate.openstack.org/iteration/view/cinder/stable-ocata

Sean McGinnis wrote on 8/5/2017 1:42 AM:
>> I think the importance of string freeze for server projects (e.g., cinder,
>> nova, keystone, neutron) might
>> be less important than previous cycle(s), but sharing the status to all the
>> teams including release management team
>> is a good idea to stay on the same page as much as possible :)
>>
> Hey Ian,
>
> Do you think we should make any changes to our policy for this? Just one thing
> that comes to mind, for server projects should we just send out a ML post with
> something like "Here is a list of patches we deemed important that had string
> translations".
>
> Just thinking of how we can keep things moving when needed while still making
> sure important things are communicated well.
>
> Or is that even too much? During soft string freeze, should the server project
> core teams just try to be more aware of these but just approve patches that
> are important fixes and move on?
>
> Thanks,
> Sean
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev