
<html><body>

<p><font size="2" face="sans-serif">As requested in the last Oslo meeting, I created a blueprint for further discussion on the i18n work in Icehouse here: </font><br>

<br>

<a href="https://blueprints.launchpad.net/oslo/+spec/i18n-messages"><font size="3" color="#0000FF" face="serif"><u>https://blueprints.launchpad.net/oslo/+spec/i18n-messages</u></font></a><font size="3" face="serif"> </font><br>

<br>

<font size="2" face="sans-serif">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.</font><br>

<br>

<font size="2" face="sans-serif">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.</font><br>

<br>

<font size="2" face="sans-serif">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</font><br>

<font size="2" face="sans-serif">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</font><br>

<font size="2" face="sans-serif">dealing with Messages and strings (unicode strings only hopefully.) </font><br>

<br>

<font size="2" face="sans-serif">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</font><br>

<font size="2" face="sans-serif">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". </font><br>

<font size="2" face="sans-serif">Changing projects to expect/use Messages instead of strings/unicode is necessary if our goal is to make Messages less magical.</font><br>

<font size="2" face="sans-serif">Some of the changes that need to be done to realize this are outlined in the blueprint,  but the big ones are:</font><br>

<font size="2" face="sans-serif"> - needing a better defined public API for messages like the translate() function</font><br>

<font size="2" face="sans-serif"> - 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)</font><br>

<font size="2" face="sans-serif"> - catch any Messages and resolve to unicode before they exit any OpenStack code</font><br>

<br>

<font size="2" face="sans-serif">Any feedback on the blueprint or ML would be appreciated.</font><br>

<br>

<font size="2" face="sans-serif">Thanks,</font><br>

<br>

<font size="2" face="sans-serif">Mathew Odden, Software Developer<br>

IBM STG OpenStack Development</font></body></html>