qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code


From: Markus Armbruster
Subject: Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code
Date: Wed, 26 Aug 2015 14:04:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Daniel P. Berrange" <address@hidden> writes:

> On Wed, Aug 26, 2015 at 08:46:35AM +0200, Gerd Hoffmann wrote:
>>   Hi,
>> 
>> > > It seems the only thing that we really care about being localized is
>> > > the messages catalogue, so the GTK UI gets internationalization in
>> > > its menus / dialogs / etc. As such I think that we should do the
>> > > opposite of (C). ie run every LC_* in the C locale, except for
>> > > LC_MESSAGES which we allow to be localized.
>> > > 
>> > > This avoids any unpredictable functional consequences (like number
>> > > formatting) while still giving user decent localization in the UI
>> > 
>> > Except that the LC_MESSAGES catalog may include messages such as "blah
>> > %d blah" that get translated for use as a printf argument, and the lack
>> > of matching LC_NUMERIC will make the translation look wrong.
>> > Translators often assume that their translation is being used with
>> > everything else about the locale matching the locale of the translation.
>> 
>> I don't think this is a big issue in practice.  The menu item names are
>> pretty much the only thing translated in the qemu gtk ui ...
>
> Also we're talking about a tradeoff between functionally incorrect
> formatting of JSON, vs "wrong looking" translations with no functional
> impact, which probably won't even affect QEMU in reality.
>
> In terms of minimizing hacks to QEMU, it seems like only localizing
> LC_MESSAGES is a simple enough tradeoff to avoid functionally
> incorrect behaviour with minimal downside and no code complexity
> messing around with thread-locales, etc

It's a hack, and as such it needs a fat comment explaining it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]