Hello, First of all, a little bit sorry for following this thread late. I am a Korean translator. Translation is also one of important and vital parts within OpenStack "Big Tent". Although the hard string freeze period before final release date is only for 3 weeks, many I18n language teams focus on translations during that period intensively. For example, Horizon translation results on lots of languages have been already included since several past releases. For nova and many other projects, the translation focus depends on different language teams. Luigi Toscano wrote on 9/12/2016 9:04 PM:

On Friday, 9 September 2016 14:12:51 CEST Matt Riedemann wrote:

...

On 9/9/2016 1:58 PM, Ben Swartzlander wrote:

...

On 09/08/2016 08:37 PM, Matt Riedemann wrote:

...

...

Hi,

I was looking for some clarity around backports of bug fixes that qualify the stable branch policy [1]. <http://docs.openstack.org/project-team-guide/stable-branches.html#appro priate-fixes>

What is the policy if the fix introduces a new translatable string or modifies an existing one?

The guidelines in Release management [2] <http://docs.openstack.org/project-team-guide/release-management.html> regarding string freeze do not specifically call this scenario out. I see that while translatable strings are mostly avoided, some projects have been merging changes to stable branches with introduction of new translatable strings.

The question is reminiscent of one posed in the ML a few releases ago [3]; <http://lists.openstack.org/pipermail/openstack-dev/2015-September/07394 2.html>

but applies to stable branches. Should we allow changes to translatable strings for bug fixes that matter, or is it better to always deny them for the sake of translation accuracy? The former IMO, a high severity bug fix trumps a translation. Note that some projects are translated on the stable branches too, I know this is

On 9/8/2016 7:05 PM, Ravi, Goutham wrote: the case for Nova.

If it's a user-facing change, like an error message in the API, then it might require a bit more careful consideration, but if it's just a log message marked for translation that an end user of the API wouldn't see anyway, then I think it's fine to backport it. So this stance makes sense to me, but I can't reconcile it with the "hard string freeze" rules. Is the theory that after we release, the string freeze ends for the stable branch, and that the hard string freeze only exists for that 3 week period between RC1 and final release, or is the theory that hard string freeze is always subject to exceptions for "critical" bug fixes?

I treat it as the former. Interesting: I'm not a translator in the OpenStack project, but I contribute as translator to other Free Software communities and I would thought as the latter as more appropriate. Stable is stable and string changes should be approved on a case-by-case, otherwise translator's life can be more complicated especially when the next release is translated.

But as I said I'm not a translator here.

Currently my suggestion is the latter, not former, and if some exception is needed, then writing and sharing such as http://lists.openstack.org/pipermail/openstack-i18n/2016-September/002402.ht... would be nice. However, it seems that there are some more things to be elaborated such as: - Need to identify how many projects are interested in translation especially for hard string freeze in different language teams - Although strings are hard-freezed, some strings will not appropriate to be translatable. It can be from misuse of ungettext() and ungettext_lazy() functions. - Or translators may find source string typos. Should they be included into stable branch? - Notification to exceptional cases to I18n team is needed. - ... I would like to copy this thread to openstack-i18n mailing list, and also discuss those things with many translators to find great solutions. If there is some better idea, please share it :) With many thanks, /Ian