openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Wed, Dec 8, 2010 at 8:11 AM, Soren Hansen <soren@xxxxxxxxxx> wrote:
> 2010/12/2 Tushar Patil <tpatil@xxxxxxxxxxxx>:
>> 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.
>
> This is how we should do it.

Yup, this is the standard.  Let us please follow the standard.  I've
used this in both C++ and Python projects in the past and it works
just great.

>> 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 _()?
>
> It's certainly possible, but it makes it /extremely/ tedious to
> discover all the strings that need translation. That's why you put _()
> at the place where the string is defined. Then there are tools that
> can extract the strings and put them into a pot file.

Agreed.  We should avoid this if possible.

>> 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 don't understand this prioritisation. I would have done it
> completely opposite. When you catch an exception and output something,
> that's when you're trying to communicate something directly to a user.
> Log messages are rarely interesting, and when they are, there's a lot
> of value in being able to take the logs and post them somewhere so
> other people can see them, but if they're in a foreign language (or
> even script), it's of no use.

Very much agreed.  I'm not sure why we should prioritize the harder,
non-standard solution over the easier, non-standard one.

It would be trivial to convert all of Nova into a full-fledged
i18n/l10n project.  I can likely do a single merge proposal that does
this, and then once it's done I can work with Monty Taylor to automate
the message build process and hook it up into Launchpad.

I can do this one merge proposal this weekend.  It would be good if we
could have a mini-freeze of code merges for 6-8 hours over the weekend
because my patch will touch virtually all source files and make
conflict hell for others trying to merge afterwards.

-jay