[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[openstack-dev] [oslo][i18n] Dropping lazy translation support

On 8/28/19 5:13 AM, Luigi Toscano wrote:
> On Monday, 19 August 2019 19:17:08 CEST Ben Nemec wrote:
>> On 8/19/19 7:46 AM, Shengjing Zhu wrote:
>>> Sorry for replying the old mail, and please cc me when reply.
>>> Matt Riedemann <mriedemos at gmail.com> writes:
>>>> This is a follow up to a dev ML email [1] where I noticed that some
>>>> implementations of the upgrade-checkers goal were failing because some
>>>> projects still use the oslo_i18n.enable_lazy() hook for lazy log message
>>>> translation (and maybe API responses?).
>>>> The very old blueprints related to this can be found here [2][3][4].
>>>> If memory serves me correctly from my time working at IBM on this, this
>>>> was needed to:
>>>> 1. Generate logs translated in other languages.
>>>> 2. Return REST API responses if the "Accept-Language" header was used
>>>> and a suitable translation existed for that language.
>>>> #1 is a dead horse since I think at least the Ocata summit when we
>>>> agreed to no longer translate logs since no one used them.
>>>> #2 is probably something no one knows about. I can't find end-user
>>>> documentation about it anywhere. It's not tested and therefore I have no
>>>> idea if it actually works anymore.
>>>> I would like to (1) deprecate the oslo_i18n.enable_lazy() function so
>>>> new projects don't use it and (2) start removing the enable_lazy() usage
>>>> from existing projects like keystone, glance and cinder.
>>>> Are there any users, deployments or vendor distributions that still rely
>>>> on this feature? If so, please speak up now.
>>> I was pointed to this discussion when I tried to fix this feature in
>>> keystone, https://review.opendev.org/677117
>>> For #2 translated API response, this feature probably hasn't been
>>> working for some time, but it's still a valid user case.
>>> Has the decision been settled?
>> Not to my knowledge. Lazy translation still exists, but I don't know
>> that anyone is testing it.
>> Are you saying that you are using this feature now, or are you
>> interested in using it going forward?
> A related note: we nuked enable_lazy in sahara because it broke Python 3
> support in mysterious ways:
> https://review.opendev.org/#/c/626643/

Hmm, we did a bad thing in the Message API. :-(

We shadowed the built-in translate function, so if translate gets called 
on a Message object it goes to our code instead of the stdlib code.

I proposed https://review.opendev.org/#/c/679092/ which would fix the 
bug you saw. It's not perfect, but at least it mitigates the problem 
since translate is part of the public API and we can't just rename it.