openstack team mailing list archive

[Monty Taylor <monty.taylor@xxxxxxxxxxxxx>]

I am more in favor of option 1. I know it means a large patch up front -
but the strings to be translated have to be identified in some manner to
create the .pot files. If we don't use the normal tooling to do this,
we're going to wind up writing our own tools to generate a .pot file
somehow.

In any case, once we have a .pot file we can use launchpad to translate
it - I think the main concern from my end is the tooling that will be
required to support the clever approach.

On 12/03/2010 12:58 PM, Anne Gentle wrote:
> Thanks Tushar for sending this and keeping the conversation going.
> Putting this thread on the openstack mailing list - rather than clicking
> the "Contact this team" link, feel free to send this to the OpenStack
> list for discussion. And let me know if that's incorrect thinking,
> everyone. :)
> 
> Just to put a doc perspective on this - I am interested in using the
> gettext module because 1.1 Sphinx apparently will support gettext
> translations and the current developer builds of Sphinx do support it
> already. The only caveat I know of is that the workflow is still under
> review for how Launchpad typically handles PO files. See
> http://bitbucket.org/birkenfeld/sphinx/issue/561/configuration-option-store-translations-in
> - and tell me if you have opinions on its affect for OpenStack
> translations going forward.
> 
> Before working on RST-based translations, however, I think it best to
> use the wiki for translated pages or writing in your native language.
> Use these instructions:
> http://moinmo.in/MoinDev/Translation#Creating_new_pages to create a
> translated page on the wiki.
> 
> I'm not giving a vote for either approach, but letting you know about
> potential doc impact in the decision process. We can all use more
> education about how Launchpad works with translations, also.
> 
> Thanks,
> Anne
> 
> On Thu, Dec 2, 2010 at 4:57 PM, Tushar Patil <tpatil@xxxxxxxxxxxx
> <mailto:tpatil@xxxxxxxxxxxx>> wrote:
> 
>     Hi Jay,
> 
>     In the last meeting, it came out with 2 approaches to support i18N in
>     nova.
> 
>     1) Using gettext module. Wrapping _() for all the logging messages.
>     This has a huge impact on the code. On the other hand in my
>     understanding we would benefit by translation of strings in different
>     languages using launchpad translation process. Currently Launchad is not
>     enabled for translation management.
>     We would need this very soon.
> 
>     2) automatically call _() on log messages with the nova/log.py that is
>     in lp:~xtoddx/nova/newlog
>     Minimal change in the code. But I am not sure if in this case it is
>     possible to use launchpad translation process.
>     xtoddx : Is it possible to call _()?
> 
>     In bexar release, we are planning to support i18n changes only related
>     to the logging messages.
>     In future, this would be extended to the exception handling messages and
>     responses to the client request.
> 
>     I think it is very important to decide which approach would best fit in
>     long run.
> 
>     Jay pipes, Monty Taylor and everyone please comment on this.
> 
>     Tushar Patil.
>     --
>     This message was sent from Launchpad by
>     Tushar Patil (https://launchpad.net/~tpatil
>     <https://launchpad.net/%7Etpatil>)
>     to each member of the Nova team using the "Contact this team" link
>     on the
>     Nova team page (https://launchpad.net/~nova
>     <https://launchpad.net/%7Enova>).
>     For more information see
>     https://help.launchpad.net/YourAccount/ContactingPeople
> 
> 



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.