<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 16, 2013 at 11:55 AM, John S Warren <span dir="ltr"><<a href="mailto:jswarren@us.ibm.com" target="_blank">jswarren@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">With regard to</font>
<br><a href="https://blueprints.launchpad.net/oslo/+spec/i18n-messages" target="_blank"><font face="sans-serif">https://blueprints.launchpad.net/oslo/+spec/i18n-messages</font></a>
<br>
<br><font face="sans-serif">I think it would be helpful to define
the high-level design</font>
<br><font face="sans-serif">alternatives, before delving into technical
details such as</font>
<br><font face="sans-serif">"magic". To that end,
here are the alternatives as I see them:</font>
<br>
<br><font face="sans-serif">1. Attempt as much as possible to isolate
the complexity of lazy</font>
<br><font face="sans-serif"> translation to the shared
oslo code. This would entail keeping the</font>
<br><font face="sans-serif"> current approach of an
alternative "_" method implementation, but</font>
<br><font face="sans-serif"> altering it so that it
produces objects that mimic as much as</font>
<br><font face="sans-serif"> possible six.text_type
objects (all existing behaviors supported,</font>
<br><font face="sans-serif"> i.e. only new behaviors
added), so that developers who are not</font>
<br><font face="sans-serif"> concerned with internationalization
can continue to work with objects</font>
<br><font face="sans-serif"> created by this method
as they have in the past, blissfully unaware</font>
<br><font face="sans-serif"> that anything has changed.
All indications are that this approach</font>
<br><font face="sans-serif"> would entail the need to
extend the six.text_type (unicode in py27)</font>
<br><font face="sans-serif"> class and would bring "magic"
into play.</font>
<br><font face="sans-serif">2. Limit the complexity of the shared
oslo code and explicitly shift</font>
<br><font face="sans-serif"> some of it to the consuming
projects. This would entail abandoning</font>
<br><font face="sans-serif"> the approach of replacing
the "_" method, and instead creating in</font>
<br><font face="sans-serif"> olso a very simple class
or set of classes to handle</font>
<br><font face="sans-serif"> internationalization concerns.
In all cases where lazy translation</font>
<br><font face="sans-serif"> needs to occur in the consuming
projects, existing use of the "_"</font>
<br><font face="sans-serif"> method would need to be
replaced with explicit use of the shared oslo</font>
<br><font face="sans-serif"> logic, so developers are
aware that they are dealing with special,</font>
<br><font face="sans-serif"> "translatable"
objects that do not behave the way six.text_type</font>
<br><font face="sans-serif"> objects do. This
would likely be extremely disruptive to the</font>
<br><font face="sans-serif"> consuming projects and
it would likely not be possible to implement</font>
<br><font face="sans-serif"> a simple "switch"
to enable or disable lazy translation.</font>
<br><font face="sans-serif">3. Limit the complexity of the shared
olso code and shift some of it to</font>
<br><font face="sans-serif"> the consuming projects,
but still keep the approach of a replacement</font>
<br><font face="sans-serif"> "_" method implementation.
This would mean that it is not clear to</font>
<br><font face="sans-serif"> developers who are not
fully versed in the lazy translation efforts</font>
<br><font face="sans-serif"> that they are not dealing
with six.text_type objects when working with</font>
<br><font face="sans-serif"> the objects returned by
the "_" method. This is the approach that has</font>
<br><font face="sans-serif"> been used so far and one
consequence was a last-minute need to disable</font>
<br><font face="sans-serif"> lazy translation, because
of key differences in how six.text_type</font>
<br><font face="sans-serif"> instances behave compared
to other types. Problems caused by</font>
<br><font face="sans-serif"> these differences are likely
to surface again, especially when</font>
<br><font face="sans-serif"> passing these objects to
external libraries.</font>
<br></blockquote><div><br></div><div>This doesn't quite match my understanding.</div><div><br></div><div>IIUC, approach 1 was taken during havana and the resulting class did not behave enough like a string to work everywhere (specifically, with logging for locales that did not use UTF-8 or ASCII encoding), so the feature was disabled at the last minute.</div>
<div><br></div><div>Option 3 is closer to the new plan for Icehouse, which is to have _() return a Message, allow Message to work in a few contexts like a string (so that, for example, log calls and exceptions can be left alone, even if they use % to combine a translated string with arguments), but then have the logging and API code explicitly handle the translation of Message instances so we can always pass unicode objects outside of OpenStack code (to logging or to web frameworks). Since the logging code is part of Oslo and the API code can be, this seemed to provide isolation while removing most of the magic.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><font face="sans-serif">Hope that's useful.</font>
<br><span class="HOEnZb"><font color="#888888">
<br><font face="sans-serif">John Warren</font></font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>