<font size=2 face="sans-serif">With regard to</font>
<br><a href="https://blueprints.launchpad.net/oslo/+spec/i18n-messages"><font size=2 face="sans-serif">https://blueprints.launchpad.net/oslo/+spec/i18n-messages</font></a>
<br>
<br><font size=2 face="sans-serif">I think it would be helpful to define
the high-level design</font>
<br><font size=2 face="sans-serif">alternatives, before delving into technical
details such as</font>
<br><font size=2 face="sans-serif">"magic".  To that end,
here are the alternatives as I see them:</font>
<br>
<br><font size=2 face="sans-serif">1. Attempt as much as possible to isolate
the complexity of lazy</font>
<br><font size=2 face="sans-serif">   translation to the shared
oslo code.  This would entail keeping the</font>
<br><font size=2 face="sans-serif">   current approach of an
alternative "_" method implementation, but</font>
<br><font size=2 face="sans-serif">   altering it so that it
produces objects that mimic as much as</font>
<br><font size=2 face="sans-serif">   possible six.text_type
objects (all existing behaviors supported,</font>
<br><font size=2 face="sans-serif">   i.e. only new behaviors
added), so that developers who are not</font>
<br><font size=2 face="sans-serif">   concerned with internationalization
can continue to work with objects</font>
<br><font size=2 face="sans-serif">   created by this method
as they have in the past, blissfully unaware</font>
<br><font size=2 face="sans-serif">   that anything has changed.
 All indications are that this approach</font>
<br><font size=2 face="sans-serif">   would entail the need to
extend the six.text_type (unicode in py27)</font>
<br><font size=2 face="sans-serif">   class and would bring "magic"
into play.</font>
<br><font size=2 face="sans-serif">2. Limit the complexity of the shared
oslo code and explicitly shift</font>
<br><font size=2 face="sans-serif">   some of it to the consuming
projects.  This would entail abandoning</font>
<br><font size=2 face="sans-serif">   the approach of replacing
the "_" method, and instead creating in</font>
<br><font size=2 face="sans-serif">   olso a very simple class
or set of classes to handle</font>
<br><font size=2 face="sans-serif">   internationalization concerns.
 In all cases where lazy translation</font>
<br><font size=2 face="sans-serif">   needs to occur in the consuming
projects, existing use of the "_"</font>
<br><font size=2 face="sans-serif">   method would need to be
replaced with explicit use of the shared oslo</font>
<br><font size=2 face="sans-serif">   logic, so developers are
aware that they are dealing with special,</font>
<br><font size=2 face="sans-serif">   "translatable"
objects that do not behave the way six.text_type</font>
<br><font size=2 face="sans-serif">   objects do.  This
would likely be extremely disruptive to the</font>
<br><font size=2 face="sans-serif">   consuming projects and
it would likely not be possible to implement</font>
<br><font size=2 face="sans-serif">   a simple "switch"
to enable or disable lazy translation.</font>
<br><font size=2 face="sans-serif">3. Limit the complexity of the shared
olso code and shift some of it to</font>
<br><font size=2 face="sans-serif">   the consuming projects,
but still keep the approach of a replacement</font>
<br><font size=2 face="sans-serif">   "_" method implementation.
 This would mean that it is not clear to</font>
<br><font size=2 face="sans-serif">   developers who are not
fully versed in the lazy translation efforts</font>
<br><font size=2 face="sans-serif">   that they are not dealing
with six.text_type objects when working with</font>
<br><font size=2 face="sans-serif">   the objects returned by
the "_" method.  This is the approach that has</font>
<br><font size=2 face="sans-serif">   been used so far and one
consequence was a last-minute need to disable</font>
<br><font size=2 face="sans-serif">   lazy translation, because
of key differences in how six.text_type</font>
<br><font size=2 face="sans-serif">   instances behave compared
to other types.  Problems caused by</font>
<br><font size=2 face="sans-serif">   these differences are likely
to surface again, especially when</font>
<br><font size=2 face="sans-serif">   passing these objects to
external libraries.</font>
<br>
<br><font size=2 face="sans-serif">Hope that's useful.</font>
<br>
<br><font size=2 face="sans-serif">John Warren</font>