Open Stack

Thierry Carrez <thierry at openstack.org> wrote:

> Matt Riedemann wrote:
>> I don't think we have an official policy for stable backports with
>> respect to translatable string changes.
>>
>> I'm looking at a release request for ironic-inspector on stable/liberty
>> [1] and one of the changes in that has translatable string changes to
>> user-facing error messages [2].
>>
>> mrunge brought up this issue in the stable team meeting this week also
>> since Horizon has to be extra careful about backporting changes with
>> translatable string changes.
>>
>> I think on the server side, if they are changes that just go in the
>> logs, it's not a huge issue. But for user facing changes, should we
>> treat those like StringFreeze [3]? Or only if the stable branches for
>> the given project aren't getting translation updates? I know the server
>> projects (at least nova) is still get translation updates on
>> stable/liberty so if we do backport changes with translatable string
>> updates, they aren't getting updated in stable. I don't see anything
>> like that happening for ironic-inspector on stable/liberty though.
>>
>> Thoughts?
>
> My take would be, you generally shouldn't change the strings in a stable  
> branch... Some people might rely on certain patterns in logs and others  
> might find it funny if a previously-translated string suddenly becomes  
> untranslated.
>
> Now there can be exceptions, where the value of changing the string  
> outweighs the value of not changing it (like, the error message itself  
> was wrong)... but it should really be an exception ?

Also, sometimes the only thing that changed is translation domain (f.e. _LE  
-> _LW). In that case, I think we should just retain the translation  
domain, but log it with proper log level. So you may have something like:

LOG.warn(_LE(‘…’))

Note that it will trigger pep8 check failure in some projects that have a  
hacking rule that validates the domain corresponds to translation marker.  
That can be overcome by ‘#  noqa’ comment in the same line.

For reference, we are looking at applying the approach here for neutron:

https://review.openstack.org/#/c/270622/4/neutron/agent/linux/external_process.py

Ihar