Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
On Thu, Mar 06, 2014 at 03:46:24PM -0600, 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/78095 Remove 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/78096 Remove use of str() on exceptions Since we're not supporting Py3 anytime soon, this patch does not seem important enough to justify for FFE. Anytime we do Py3 portability fixes I'd also expect there to be some hacking check testing that validate we won't regress in that in the future too. (4) The addition of the call that enables the use of lazy messages. This is in: https://review.openstack.org/#/c/73706 Re-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. I'll be a sponsor once there is a clear solution proposed to the bug in point 1. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
On 03/06/2014 04: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. Unless it has landed in *every other* integrated project besides Nova, I don't find this compelling. 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. If this is enabled in other projects, where is the Tempest scenario test that actually demonstrates that this is working on real installs? I get that everyone has features that didn't hit. BHowever now is not that time for that, now is the time for people to get focussed on bugs hunting. And especially if we are talking about *another* oslo sync. -1 -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
On 3/7/2014 3:23 AM, Daniel P. Berrange wrote: On Thu, Mar 06, 2014 at 03:46:24PM -0600, 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/78095 Remove 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/78096 Remove use of str() on exceptions Since we're not supporting Py3 anytime soon, this patch does not seem important enough to justify for FFE. Anytime we do Py3 portability fixes I'd also expect there to be some hacking check testing that validate we won't regress in that in the future too. (4) The addition of the call that enables the use of lazy messages. This is in: https://review.openstack.org/#/c/73706 Re-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. I'll be a sponsor once there is a clear solution proposed to the bug in point 1. Regards, Daniel As far as I understand this is not a py3 issue, six.text_type was being used because the alternative was converting usage of str() to unicode() and that doesn't work with py3, so six.text_type is used. I agree that if all instances of str() in Nova need to be changed to six.text_type for this to work we need a hacking check for it. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
On 3/7/2014 4:15 AM, Sean Dague wrote: On 03/06/2014 04: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. Unless it has landed in *every other* integrated project besides Nova, I don't find this compelling. 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. If this is enabled in other projects, where is the Tempest scenario test that actually demonstrates that this is working on real installs? I get that everyone has features that didn't hit. BHowever now is not that time for that, now is the time for people to get focussed on bugs hunting. And especially if we are talking about *another* oslo sync. -1 -Sean ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The Tempest requirement just came up yesterday. FWIW, this i18n stuff has been working it's way in since Grizzly, and the new requirement for Tempest is new. I'm not saying it's not valid, but the timing sucks - but that's life. Also, the oslo sync would be to one module, gettextutils, which I don't think pulls in anything else from oslo. Anyway, this is in Keystone, Glance, Cinder, Neutron and Ceilometer at least. Patches are working their way through Heat as I understand it. I'm not trying to turn this into a crusade, just trying to get out what I know about the current state of things. I'll let Jim Carey or Jay Bryant discuss it more since they've been more involved in the blueprints across all the projects. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
From: Sean Dague s...@dague.net To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 03/07/2014 04:25 AM Subject:Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements On 03/06/2014 04: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. Unless it has landed in *every other* integrated project besides Nova, I don't find this compelling. 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. If this is enabled in other projects, where is the Tempest scenario test that actually demonstrates that this is working on real installs? I get that everyone has features that didn't hit. BHowever now is not that time for that, now is the time for people to get focussed on bugs hunting. And especially if we are talking about *another* oslo sync. -1 -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net [attachment signature.asc deleted by Jay S Bryant/Rochester/IBM] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sean, I really feel like this is being made into a bigger deal than it needs to be. The only other project that hasn't accepted this change is Heat and we are currently working to resolve that issue. We were not aware of a requirement for Tempest tests for a change like this. We would be willing to work on getting those added to resolve that issue. If we were to get these added ASAP would you be willing to reconsider? As far as the Oslo sync is concerned, it is a sync gettextutils which is an isolated module that doesn't have other dependencies and is pulling in a number of good bug fixes. The removal of str() from LOGs and exceptions was a ticking time bomb that needed to be addressed anyway. The change brings good value for users and fixes issues that have been lying around for quite some time. We apologize that this is coming in so late in the game. There were extraneous challenges that lead to the timing on this. Thank you for your consideration on this issue. Jay S. Bryant IBM Cinder Subject Matter ExpertCinder Core Member___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
On 03/07/2014 12:09 PM, Matt Riedemann wrote: Dan (Smith), Sean, Jim, Jay and myself talked about this in IRC this morning and I didn't realize the recent oslo bug was uncovered due to something changing in how the audit logs were showing up after the initial nova patch was pushed up on 2/14. So given that, given the number of things that would still need to land (oslo patch/sync plus possibly a hacking rule for str-six.text_type) AND the (despite being late) Tempest test requirement, I'm dropping sponsorship for this. It simply came in too late and is too risky at this point, so let's revisit in Juno and get it turned on early so everyone can be comfortable with it. OK. Thanks a lot to everyone who helped evaluate this. Hopefully we can get it sorted early in Juno, then. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
From: Russell Bryant rbry...@redhat.com To: openstack-dev@lists.openstack.org, Date: 03/07/2014 11:31 AM Subject:Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements On 03/07/2014 12:09 PM, Matt Riedemann wrote: Dan (Smith), Sean, Jim, Jay and myself talked about this in IRC this morning and I didn't realize the recent oslo bug was uncovered due to something changing in how the audit logs were showing up after the initial nova patch was pushed up on 2/14. So given that, given the number of things that would still need to land (oslo patch/sync plus possibly a hacking rule for str-six.text_type) AND the (despite being late) Tempest test requirement, I'm dropping sponsorship for this. It simply came in too late and is too risky at this point, so let's revisit in Juno and get it turned on early so everyone can be comfortable with it. OK. Thanks a lot to everyone who helped evaluate this. Hopefully we can get it sorted early in Juno, then. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev All, Thanks for taking the time to consider/discuss this. Some good lessons learned on this end. Look forward to getting this in early in Juno. Jay S. Bryant IBM Cinder Subject Matter ExpertCinder Core Member___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
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/78095 Remove 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/78096 Remove 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/73706 Re-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
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
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. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
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
Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements
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
