On Thu, Mar 6, 2014 at 8:24 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > > > 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/ >
Being there are some testing desires for this, and the fix hasn't landed in oslo-incubator yet, I am -1 on this. > > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev