Open Stack

-------- Original Message --------
Subject: 	[openstack-dev] [oslo] i18n Message improvements
Date: 	Tue, 15 Oct 2013 17:40:56 -0500
From: 	Mathew R Odden <mrodden at us.ibm.com>
Reply-To: 	OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
To: 	OpenStack Development Mailing List <openstack-dev at lists.openstack.org>



As requested in the last Oslo meeting, I created a blueprint for further
discussion on the i18n work in Icehouse here:

_https://blueprints.launchpad.net/oslo/+spec/i18n-messages_

There were some ideas from the meeting that I'm sure I wasn't quite
fully understanding, so please take a look and let me know if there is
any feedback.

Also, just to try to recap the discussion and try to state where *I
think* we want to head with i18n/Messages, this is where I think we want
to go in Icehouse.

Make Message objects in oslo less magical by removing a lot of the magic
string methods/operators from the class. This doesn't necessarily mean
removing all
of the "magic" operators (I think __mod__ is still necessary, as pointed
out in the whiteboard of the blueprint.) I think some of the
functionality is useful to developers when
dealing with Messages and strings (unicode strings only hopefully.)

The overall shift in direction should be to make projects more aware of
the Message objects, and we need to change those to utilize them better
instead of trying
to make Messages work in all project cases. This was one of the biggest
challenges of how it works today; trying to make a Message into a "string".
Changing projects to expect/use Messages instead of strings/unicode is
necessary if our goal is to make Messages less magical.
Some of the changes that need to be done to realize this are outlined in
the blueprint,  but the big ones are:
   - needing a better defined public API for messages like the
translate() function
   - needing to utilize unicode (more likely six.text_type) in all areas
in OpenStack projects instead of strings (although we should be trying
to do this already)
   - catch any Messages and resolve to unicode before they exit any
OpenStack code

Any feedback on the blueprint or ML would be appreciated.

Thanks,

Mathew Odden, Software Developer
IBM STG OpenStack Development



-------------- next part --------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev