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:
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.