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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
