qemu-devel
[Top][All Lists]
Advanced

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

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 7/9] gtk: add translation support (v5)
Date: Wed, 20 Feb 2013 18:19:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 20.02.2013 17:53, schrieb Daniel P. Berrange:
> On Wed, Feb 20, 2013 at 05:24:02PM +0100, Andreas Färber wrote:
>> Am 20.02.2013 17:16, schrieb Daniel P. Berrange:
>>> On Wed, Feb 20, 2013 at 05:10:54PM +0100, Andreas Färber wrote:
>>>> 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.
>>>>
>>>> Better would be to use unique alphanumeric identifiers (e.g.,
>>>> "Menu.File.Quit") and to have a regular translation file for en (or
>>>> whatever suitable as fallback).
>>>
>>> Your points may be valid, but this patch follows standard practice for
>>> i18n of any GTK app, in fact standard across pretty much all open
>>> source projects I've worked on. I don't think QEMU should try to do
>>> something non-standard for translation files.
>>
>> Not having translations may be better quality-wise than having known
>> broken translations just because that is considered standard practice by
>> English speakers that don't actually see or need them.
> 
> People doing the translations simply need to be aware of the issue and
> look at the context of the usage. Developes can help them do this by
> putting special comments in the source code to provide hints on context
> eg
> 
>   /* TRANSLATORS: ....some hint texts.... */
>   foo(_("Some string"))
> 
> this text gets copied into the .pot file
> 
>   #. TRANSLATORS: ...some hint texts...
>   #: filename.c
>   msgid "Some string"
>   msgstr ""
> 
> so the translators can then understand the usage context & do the right
> translation.

You're missing my point: The problem is the msgid "Foo" line unless you
get msgid "Foo" for each occurrence of _L("Foo") rather than once. If
the tools allow per-occurrence translations then everything is fine,
with or without comments. Problem is only when tools try to be clever.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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