[Openstack] i18n proposed plan

2010-12-08 Thread Jay Pipes
Hi all, Here is my proposed solution for getting Nova i18n'd. Normally, I'd "just do it", but in this particular case, the code I'll commit will affect virtually all source pages, so it needs to be handled properly to avoid wasting developers time resolving merge conflicts from this large patch.

Re: [Openstack] i18n support in nova

2010-12-08 Thread John Purrier
Yes, let's do the standard approach, no matter how easy! -johnpur -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Wednesday, December 08, 2010 10:42 AM To: So

Re: [Openstack] i18n support in nova

2010-12-08 Thread Jay Pipes
On Wed, Dec 8, 2010 at 11:40 AM, Jay Pipes wrote: > Very much agreed.  I'm not sure why we should prioritize the harder, > non-standard solution over the easier, non-standard one. Oops, meant easier, standard one :) --jay ___ Mailing list: https://lau

Re: [Openstack] i18n support in nova

2010-12-08 Thread Jay Pipes
On Wed, Dec 8, 2010 at 8:11 AM, Soren Hansen wrote: > 2010/12/2 Tushar Patil : >> 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

Re: [Openstack] i18n support in nova

2010-12-08 Thread Soren Hansen
2010/12/2 Tushar Patil : > 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