Open Stack

With regard to
https://blueprints.launchpad.net/oslo/+spec/i18n-messages

I think it would be helpful to define the high-level design
alternatives, before delving into technical details such as
"magic".  To that end, here are the alternatives as I see them:

1. Attempt as much as possible to isolate the complexity of lazy
   translation to the shared oslo code.  This would entail keeping the
   current approach of an alternative "_" method implementation, but
   altering it so that it produces objects that mimic as much as
   possible six.text_type objects (all existing behaviors supported,
   i.e. only new behaviors added), so that developers who are not
   concerned with internationalization can continue to work with objects
   created by this method as they have in the past, blissfully unaware
   that anything has changed.  All indications are that this approach
   would entail the need to extend the six.text_type (unicode in py27)
   class and would bring "magic" into play.
2. Limit the complexity of the shared oslo code and explicitly shift
   some of it to the consuming projects.  This would entail abandoning
   the approach of replacing the "_" method, and instead creating in
   olso a very simple class or set of classes to handle
   internationalization concerns.  In all cases where lazy translation
   needs to occur in the consuming projects, existing use of the "_"
   method would need to be replaced with explicit use of the shared oslo
   logic, so developers are aware that they are dealing with special,
   "translatable" objects that do not behave the way six.text_type
   objects do.  This would likely be extremely disruptive to the
   consuming projects and it would likely not be possible to implement
   a simple "switch" to enable or disable lazy translation.
3. Limit the complexity of the shared olso code and shift some of it to
   the consuming projects, but still keep the approach of a replacement
   "_" method implementation.  This would mean that it is not clear to
   developers who are not fully versed in the lazy translation efforts
   that they are not dealing with six.text_type objects when working with
   the objects returned by the "_" method.  This is the approach that has
   been used so far and one consequence was a last-minute need to disable
   lazy translation, because of key differences in how six.text_type
   instances behave compared to other types.  Problems caused by
   these differences are likely to surface again, especially when
   passing these objects to external libraries.

Hope that's useful.

John Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/92571114/attachment.html>