On 3/6/2014 8:08 PM, Matt Riedemann wrote:
On 3/6/2014 3:46 PM, James Carey wrote:
Please consider a FFE for i18n Message improvements:
BP: https://blueprints.launchpad.net/nova/+spec/i18n-messages
The base enablement for lazy translation has already been sync'd
from oslo. This patch was to enable lazy translation support in Nova.
It is titled re-enable lazy translation because this was enabled
during Havana but was pulled due to issues that have since been resolved.
In order to enable lazy translation it is necessary to do the
following things:
(1) Fix a bug in oslo with respect to how keywords are extracted from
the format strings when saving replacement text for use when the message
translation is done. This is
https://bugs.launchpad.net/nova/+bug/1288049, which I'm actively working
on a fix for in oslo. Once that is complete it will need to be sync'd
into nova.
(2) Remove concatenation (+) of translatable messages. The current
class that is used to hold the translatable message
(gettextutils.Message) does not support concatenation. There were a few
cases in Nova where this was done and they are coverted to other means
of combining the strings in:
https://review.openstack.org/#/c/78095Remove use of concatenation on
messages
(3) Remove the use of str() on exceptions. The intent of this is to
return the message contained in the exception, but these messages may
contain unicode, so str cannot be used on them and gettextutils.Message
enforces this. Thus these need
to either be removed and allow python formatting to do the right thing,
or changed to unicode(). Since unicode() will change to str() in Py3,
the forward compatible six.text_type() is used instead. This is done in:
https://review.openstack.org/#/c/78096Remove use of str() on exceptions
(4) The addition of the call that enables the use of lazy messages.
This is in:
https://review.openstack.org/#/c/73706Re-enable lazy translation.
Lazy translation has been enabled in the other projects so it would
be beneficial to be consistent with the other projects with respect to
message translation. I have tested that the changes in (2) and (3) work
when lazy translation is not enabled. Thus if a problem is found, the
two line change in (4) could be removed to get to the previous behavior.
I've been talking to Matt Riedemann and Dan Berrange about this.
Matt has agreed to be a sponsor.
--Jim Carey
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jim,
Post back here with the link to the oslo-incubator fix for that bug when
you have it available, then we can look at this a bit more.
The oslo patch is here [1]. The bug report has a nice analysis of the
problem and how H501 makes it so locals() doesn't need to be handled
anymore.
If this could get into oslo quickly it could be synced to nova and the
i18n-messages patches would be rebased on top of it.
As Jim pointed out, if there was a problem with enabling lazy
translation in nova it'd be a trivial change to disable it again.
There was concern raised in IRC today about wanting a Tempest scenario
test to also hit this code, something along the lines of passing zh_CN
through the request to make sure nothing blows up. I think that's
reasonable but we'd probably need some help from the QA team in figuring
out exactly what needs to be run there. I don't have much experience
with the scenario tests, I just know their main purpose is to test
inter-service interaction.
[1] https://review.openstack.org/#/c/78806/
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev