Hi Daisy, Thanks for the feeback. Please find my comments inline. Perhaps I am just raising a question whether the string freeze works effectively for *all* projects. 2015-06-05 15:35 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:

Akihiro Motoki <amotoki@gmail.com> wrote on 2015/06/03 23:25:47:

...

From: Akihiro Motoki <amotoki@gmail.com> To: "openstack-i18n@lists.openstack.org" < Openstack-i18n@lists.openstack.org> Date: 2015/06/03 23:26 Subject: [Openstack-i18n] Thought on String Freeze

Hi I18N folks,

...

# Congratulation for the official I18N project!!

I first thought to send this mail to the dev list, but it seems better to share my thought in the I18N folks first.

...

Problems ==========

I am feeling that String Freeze does not work well in the past several releases.There are several I think we should not apply String Freeze for projects for which not so many translators work on.

As far as I understand, Horizon and documentations are targets for most translations in the past several releases. On the other hands, core reviewers of projects other than Horizon and docs (including keystone) were taking care of String Freeze exception WELL.

Thank you for bringing this topic under discussion.

Translation team focus on Horizon and document. It is true for now. But maybe in the future, it is not true. You never know some time translation team may decide to translate other projects. You don't know whether there is another group of team (not community translation team ) who are translating them.

"String freeze" is there when translation team were not set up. I don't like treating some projects differently just because translation team don't translate them now.

Do you think handling String Freeze exception is a burden ? I remember String Freeze exception emails are sent automatically, if developers add a tag to the patch.

From my experience, it is not a big burden but as a project reviewer if we can know we don't need to take care of string changes in RC phases it would be great. We sometimes put -1 only due to string changes, but no translations actually come in. As a result, taking care of string changes turns out useless efforts as a result. (Honestly I approved several patches with string changes because we didn't see any translation efforts in the

You are right to some extent, but I would like to point out that "String Freeze" only applies to the release critical period. If some team catches up its translation after the release, it is not related. I am not sure if we need to care translations which are not synced with OpenStack upstream releases. Under the "big tent" model, we have more and more projects. If we don't have translations for most of projects, there is no reason we request them to apply "string freeze" as a result. How can translation teams scale? If translation teams do not scale in the near term, doesn't it sound reasonable that we prevent non-interested project (from translation perspective) from merging changes freely? This is the background I proposed to declare *interested* project. project). Core reviewers in every project need to take care of all things before approving patches, but they have limited times and would like to spend their time on useful things, so it would be great if we can know "string freeze is effective in our project and it is useful". The all above comes from the point of project core reviewers, but I think it is worth considered. I am exploring if I18N community can make active feedbacks so that the whole dev commuty works efficiently (rather than just waiting passive response), and just raising a question from the other side (not as I18N team but a core reviewer of several projects). Thanks, Akihiro

Thoughts ?

...

My Proposal =============

...

Considering the current status, I think we should limit "String Freeze" only to projects which translators are interested in. My idea is to declare projects we would like to enable "String Freeze" just after Liberty-3 is cut. By doing so, other projects no longer need to take care of String Freeze exception.

...

(Note that the freeze date of the documentation projects are different and we can apply some different policy on documentations).

Thought? I cannot join the team meeting tomorrow due to LinuxCon/CloudOpen Japan, but I hope you will share your thought on this topic.

...

Thanks, Akihiro _______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n