Open Stack

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:
>>>> On 9/8/2016 7:05 PM, Ravi, Goutham 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
>>>> 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.html 
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