[openstack-dev] [oslo] i18n Message improvements

Doug Hellmann doug.hellmann at dreamhost.com
Wed Oct 16 19:01:13 UTC 2013


On Wed, Oct 16, 2013 at 2:04 PM, Mathew R Odden <mrodden at us.ibm.com> wrote:

> Łukasz Jernaś <deejay1 at srem.org> wrote on 10/16/2013 02:26:28 AM:
>
>
> > I'm still trying to wrap my head around the need for translating API
> > messages and log messages as IMHO it adds a lot more problems for app
> > developers  and log analysis tools, eg. a log analysis tool would be
> > usable only for the locale it was developed for and break with _every_
> > update of the translations. As a translator myself I don't really want
> > to check every system in existence if it uses my messages to do some
> > sort analysis and often change the strings to more proper form in my
> > language as reviews and feedback on the translation comes in - even
> > though the original English string doesn't change at all.
> > I feel that translating mostly computer facing stuff is just crying
> > for bugs, weird issues popping up for users, API-s should be readable
> > by humans, but translating them is a bit too far in my opinion.
>
>
> The original reason I got involved with the i18n stuff in OpenStack was
> because we had a need to be able to debug issues on system running a
> non-English locale, and therefore spitting out logs of translated messages.
> This makes it extremely difficult to debug for two reasons, the inline
> messages in code are English, and if the person doing the debugging doesn't
> understand the language the logs are in, it is obviously harder to find
> issues on the system.
>
>
> > If I get it right the Message objects are supposed to move stuff
> > around internally in a C/en locale, but we will still end up dropping
> > translated messages to computers if the don't explicitly specify the
> > locale which the request should use...
>
> Messages are designed to wrap the original inline English string, so
> that at a later time, such as outputting to a log handler or at the
> API layer when outputting an HTTP response, we can translate the
> internal string to a requested locale we may know at that time.
> The way the _() gettext function works is to translate everything
> immediately to the system locale.
>
> This leads to the two problems Messages is supposed to address:
>  1. localizable messages coming out of the API will be
>     translated to the system locale (which doesn't really make sense IMO)
>  2. log records are translated to the system locale as well, making
>     debugging issues that much more difficult on a non-English locale
>
> These could also be addressed by removing the original gettext
> immediate translation of log/API messages.
>
> Removing translation from the OpenStack server projects actually
> makes more sense to me, because, as you pointed out, they are services
> with APIs that are meant to utilized by other programs, not users
> directly. Also, there is the matter of log messages being translated,
> which makes auditing and debugging difficult, which is the primary use
> of logging facilities IMHO.
>
> I have been told several times that we can't remove the i18n functionality
> from the projects because some users want it still. I would be interested
> in hearing more from the users and developers that would like to keep
> the functionality around.
>

Error messages from the server processes are presented to the user through
the command line interface and through Horizon, so they do need to be
translated.

Log message translation is meant to help deployers, rather than end-users.
Not all deployers are going to have strong English reading skills, so
having messages translated into their native language makes it easier to
administer OpenStack.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/4191d796/attachment.html>


More information about the OpenStack-dev mailing list