Open Stack

On Wed, Oct 16, 2013 at 11:55 AM, John S Warren <jswarren at us.ibm.com> wrote:

> 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.
>

This doesn't quite match my understanding.

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.

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.

Doug


>
> Hope that's useful.
>
> John Warren
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/e7c8f958/attachment.html>