Re: [Qemu-devel] [PATCH 7/9] gtk: add translation support (v5)

[Anthony Liguori]

Andreas Färber <address@hidden> writes:

> Am 21.02.2013 09:38, schrieb Kevin Wolf:
>> On Wed, Feb 20, 2013 at 06:26:55PM +0100, Andreas Färber wrote:
>>> Am 20.02.2013 18:05, schrieb Anthony Liguori:
>>>> Andreas Färber <address@hidden> writes:
>>>>
>>>>> Am 20.02.2013 14:43, schrieb Anthony Liguori:
>>>>>> This includes a de_DE translation from Kevin Wolf and an it translation 
>>>>>> from
>>>>>> Paolo Bonzini.
>>>>>>
>>>>>> Cc: Paolo Bonzini <address@hidden>
>>>>>> Cc: Kevin Wolf <address@hidden>
>>>>>> Cc: Stefan Hajnoczi <address@hidden>
>>>>>> Signed-off-by: Anthony Liguori <address@hidden>
>>>>>> ---
>>>>>> v1 -> v4
>>>>>>  - Don't use '|| exit 1' with sub-invocation of make
>>>>>>  - Actually include Kevin's translation
>>>>>> v4 -> v5
>>>>>>  - Update translations (Kevin and Paolo)
>>>>>>  - Fix 'make update' for it.po
>>>>>> ---
>>>>>>  Makefile       |  3 +++
>>>>>>  configure      |  4 +++-
>>>>>>  po/Makefile    | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  po/de_DE.po    | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  po/it.po       | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  po/messages.po | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  ui/gtk.c       | 22 +++++++++++++++-------
>>>>>>  7 files changed, 202 insertions(+), 8 deletions(-)
>>>>>>  create mode 100644 po/Makefile
>>>>>>  create mode 100644 po/de_DE.po
>>>>>>  create mode 100644 po/it.po
>>>>>>  create mode 100644 po/messages.po
>>>>>
>>>>> IIUC this uses the English texts as key for lookup of translations.
>>>>> Experience shows that while that is most convenient for the English it
>>>>> leads to grammatical mistakes in other languages due to text reuse in
>>>>> wrong contexts. A prominent example is "Server" being translated as
>>>>> "Kellner" (which is waiter) in some early Windows NT version. :) More
>>>>> recent examples commonly found are ambiguities of, e.g., "Update" as
>>>>> noun vs. imperative - happens if the same wording is used in a menu and
>>>>> in some options dialog or status text. Similar for ing-forms translated
>>>>> as noun vs. infinitive vs. first-person present.
>>>>
>>>> Right or wrong, this is how GTK apps are written.  If you disagree with
>>>> it, take it up with the Gnome folks.  Consistency trumps "rightness"
>>>> here.
>>>
>>> You don't translate error_setg() et al., so translating a few UI items
>>> is in fact inconsistent here.
>> 
>> I think the plan with error messages was to have them translated
>> eventually, which is one of the reasons why clients may not parse them
>> (and strerror() results are already translated today).
>> 
>> But since we're using some standard GTK menu entries, not translating
>> would actually give you the much bigger inconsistency: In the same menu,
>> you would have both English and translated entries. This is what the
>> first version of this patch series had, and which I really hated.
>
> I agree that a mix of English and German is bad.
>
> Unfortunately that is exactly what I see on my German system now
> *despite* translation support (v5) being committed!

make install

Unfortunately, I have not found a way for it to pick up .mo files from
the build directory.

Regards,

Anthony Liguori

>
> Andreas
>
>> 
>> As long as there is a logical separation between translated and
>> untranslated strings (e.g. menus are translated, the monitor is English)
>> I don't see a problem with it.
>> 
>>> A more critical issue would be distro packaging though.
>>> An alternative idea would be to separate the _L() text from the English
>>> text if that is possible through some macro, cmp. reply to Daniel.
>> 
>> You want qemu to be usable with LANG=C, so using identifiers instead of
>> English texts doesn't really work. The gettext functions that allow
>> specifying a context look like a better solution to solve the problem
>> if it ever comes up.
>> 
>> Kevin
>> 
>
>
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg