* [Qemu-devel] Translation of strings in QEMU w/ gettext ?
@ 2015-06-02 12:56 Daniel P. Berrange
2015-06-02 13:20 ` Daniel P. Berrange
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Daniel P. Berrange @ 2015-06-02 12:56 UTC (permalink / raw
To: qemu-devel
In my work on TLS encryption, I've been blindly adding gettext markers
around all error messages I raise. eg error_setg(errp, _("foo bar"));
I've done this out of habit, since most apps I work on translate all
strings that could end up visible by a user.
Looking again at existing QEMU codebase though, I notice that adding
gettext _("...") markers is the exception, not the rule.
$ git grep -l '_("'
disas/alpha.c
disas/arm.c
disas/i386.c
disas/m68k.c
disas/mips.c
disas/ppc.c
disas/sparc.c
scripts/dump-guest-memory.py
tcg/s390/tcg-target.c
tcg/sparc/tcg-target.h
ui/gtk.c
Also, there are no .po file translations in QEMU source.
So I'm wondering if there is a long term vision / desire for translation
in QEMU or not ?
In a number of cases libvirt includes the error message from QMP in the
message we pass back up to the user. Any errors from libvirt are always
translated, so if running libvirt in a non-en_US locale currently you
will get a translated message from libvirt which includes a bit english
text from QEMU.
Also, with the GTK ui frontend of QEMU now, you'll get some translation
of the user interface menu options thanks to GTK built-in translations,
but the rest are still english, which is not very satisfactory either.
Should we accept and/or encourage new patches to include translation
markers, or should we explicitly say we're never going to translate any
of QEMU and remove existing _("...") usage in the code ?
I've got a bunch of patches which add _("...") and want to know whether
to remove them from my new code....
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Translation of strings in QEMU w/ gettext ?
2015-06-02 12:56 [Qemu-devel] Translation of strings in QEMU w/ gettext ? Daniel P. Berrange
@ 2015-06-02 13:20 ` Daniel P. Berrange
2015-06-02 14:34 ` Kevin Wolf
2015-06-02 14:53 ` Paolo Bonzini
2 siblings, 0 replies; 6+ messages in thread
From: Daniel P. Berrange @ 2015-06-02 13:20 UTC (permalink / raw
To: qemu-devel
On Tue, Jun 02, 2015 at 01:56:34PM +0100, Daniel P. Berrange wrote:
> In my work on TLS encryption, I've been blindly adding gettext markers
> around all error messages I raise. eg error_setg(errp, _("foo bar"));
> I've done this out of habit, since most apps I work on translate all
> strings that could end up visible by a user.
>
> Looking again at existing QEMU codebase though, I notice that adding
> gettext _("...") markers is the exception, not the rule.
>
> $ git grep -l '_("'
> disas/alpha.c
> disas/arm.c
> disas/i386.c
> disas/m68k.c
> disas/mips.c
> disas/ppc.c
> disas/sparc.c
> scripts/dump-guest-memory.py
> tcg/s390/tcg-target.c
> tcg/sparc/tcg-target.h
> ui/gtk.c
>
> Also, there are no .po file translations in QEMU source.
I'm being blind. There is a po/ directory of course :-) The questions
still stand though - should we be translating the rest of the source
beyond those files listed above.
> So I'm wondering if there is a long term vision / desire for translation
> in QEMU or not ?
>
> In a number of cases libvirt includes the error message from QMP in the
> message we pass back up to the user. Any errors from libvirt are always
> translated, so if running libvirt in a non-en_US locale currently you
> will get a translated message from libvirt which includes a bit english
> text from QEMU.
>
> Also, with the GTK ui frontend of QEMU now, you'll get some translation
> of the user interface menu options thanks to GTK built-in translations,
> but the rest are still english, which is not very satisfactory either.
>
> Should we accept and/or encourage new patches to include translation
> markers, or should we explicitly say we're never going to translate any
> of QEMU and remove existing _("...") usage in the code ?
>
> I've got a bunch of patches which add _("...") and want to know whether
> to remove them from my new code....
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Translation of strings in QEMU w/ gettext ?
2015-06-02 12:56 [Qemu-devel] Translation of strings in QEMU w/ gettext ? Daniel P. Berrange
2015-06-02 13:20 ` Daniel P. Berrange
@ 2015-06-02 14:34 ` Kevin Wolf
2015-06-02 14:40 ` Daniel P. Berrange
2015-06-02 14:53 ` Paolo Bonzini
2 siblings, 1 reply; 6+ messages in thread
From: Kevin Wolf @ 2015-06-02 14:34 UTC (permalink / raw
To: Daniel P. Berrange; +Cc: qemu-devel
Am 02.06.2015 um 14:56 hat Daniel P. Berrange geschrieben:
> In a number of cases libvirt includes the error message from QMP in the
> message we pass back up to the user. Any errors from libvirt are always
> translated, so if running libvirt in a non-en_US locale currently you
> will get a translated message from libvirt which includes a bit english
> text from QEMU.
The problem here is which locale to use. If the server uses a different
locale than the client, not much is won. Can libvirt know on startup
which language should be used?
Would we need a language per QMP connection? (Hopefully not.)
> Also, with the GTK ui frontend of QEMU now, you'll get some translation
> of the user interface menu options thanks to GTK built-in translations,
> but the rest are still english, which is not very satisfactory either.
As you noticed, this is not what happens, but I think this is the most
important point: If you translate something, translate all of it.
Mixed languages is worse than just English.
Currently the split is that the GTK UI is completely translated, and
other parts (especially the monitor) isn't translated at all. This is
a split that is easy to understand and doesn't feel like mixed
languages.
If we want to extend it to the monitor, we need to translate all of the
monitor (including all error messages that could eventually be passed to
the monitor) in the same release. Sounds not impossible, but in this
case we really can't do just half of it as we usually do with our
conversions.
Kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Translation of strings in QEMU w/ gettext ?
2015-06-02 14:34 ` Kevin Wolf
@ 2015-06-02 14:40 ` Daniel P. Berrange
2015-06-03 7:28 ` Markus Armbruster
0 siblings, 1 reply; 6+ messages in thread
From: Daniel P. Berrange @ 2015-06-02 14:40 UTC (permalink / raw
To: Kevin Wolf; +Cc: qemu-devel
On Tue, Jun 02, 2015 at 04:34:09PM +0200, Kevin Wolf wrote:
> Am 02.06.2015 um 14:56 hat Daniel P. Berrange geschrieben:
> > In a number of cases libvirt includes the error message from QMP in the
> > message we pass back up to the user. Any errors from libvirt are always
> > translated, so if running libvirt in a non-en_US locale currently you
> > will get a translated message from libvirt which includes a bit english
> > text from QEMU.
>
> The problem here is which locale to use. If the server uses a different
> locale than the client, not much is won. Can libvirt know on startup
> which language should be used?
>
> Would we need a language per QMP connection? (Hopefully not.)
Libvirt doesn't have any client selected locale - whatever locale the
libvirtd server is started in is used for all strings. This is good
enough as the most common case will be people with both client and
server using the same locale.
> > Also, with the GTK ui frontend of QEMU now, you'll get some translation
> > of the user interface menu options thanks to GTK built-in translations,
> > but the rest are still english, which is not very satisfactory either.
>
> As you noticed, this is not what happens, but I think this is the most
> important point: If you translate something, translate all of it.
> Mixed languages is worse than just English.
>
> Currently the split is that the GTK UI is completely translated, and
> other parts (especially the monitor) isn't translated at all. This is
> a split that is easy to understand and doesn't feel like mixed
> languages.
>
> If we want to extend it to the monitor, we need to translate all of the
> monitor (including all error messages that could eventually be passed to
> the monitor) in the same release. Sounds not impossible, but in this
> case we really can't do just half of it as we usually do with our
> conversions.
Well, even if all the code was translated, we would never guarantee that
all languages have 100% finished .po files. So incrementally updating the
QEMU source to mark more strings is not that different from a case where
all is marked but most translations are incomplete.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Translation of strings in QEMU w/ gettext ?
2015-06-02 12:56 [Qemu-devel] Translation of strings in QEMU w/ gettext ? Daniel P. Berrange
2015-06-02 13:20 ` Daniel P. Berrange
2015-06-02 14:34 ` Kevin Wolf
@ 2015-06-02 14:53 ` Paolo Bonzini
2 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2015-06-02 14:53 UTC (permalink / raw
To: Daniel P. Berrange, qemu-devel
On 02/06/2015 14:56, Daniel P. Berrange wrote:
> In my work on TLS encryption, I've been blindly adding gettext markers
> around all error messages I raise. eg error_setg(errp, _("foo bar"));
> I've done this out of habit, since most apps I work on translate all
> strings that could end up visible by a user.
>
> Looking again at existing QEMU codebase though, I notice that adding
> gettext _("...") markers is the exception, not the rule.
I think that _("...") markers should remain the exceptions. However, we
could autoextract for example error_setg/error_setg_errno's message
arguments into PO files.
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] Translation of strings in QEMU w/ gettext ?
2015-06-02 14:40 ` Daniel P. Berrange
@ 2015-06-03 7:28 ` Markus Armbruster
0 siblings, 0 replies; 6+ messages in thread
From: Markus Armbruster @ 2015-06-03 7:28 UTC (permalink / raw
To: Daniel P. Berrange; +Cc: Kevin Wolf, qemu-devel
"Daniel P. Berrange" <berrange@redhat.com> writes:
> On Tue, Jun 02, 2015 at 04:34:09PM +0200, Kevin Wolf wrote:
>> Am 02.06.2015 um 14:56 hat Daniel P. Berrange geschrieben:
>> > So I'm wondering if there is a long term vision / desire for translation
>> > in QEMU or not ?
I'm not aware of any plans, just idle talk every couple of years.
>> > In a number of cases libvirt includes the error message from QMP in the
>> > message we pass back up to the user. Any errors from libvirt are always
>> > translated, so if running libvirt in a non-en_US locale currently you
>> > will get a translated message from libvirt which includes a bit english
>> > text from QEMU.
>>
>> The problem here is which locale to use. If the server uses a different
>> locale than the client, not much is won. Can libvirt know on startup
>> which language should be used?
>>
>> Would we need a language per QMP connection? (Hopefully not.)
>
> Libvirt doesn't have any client selected locale - whatever locale the
> libvirtd server is started in is used for all strings. This is good
> enough as the most common case will be people with both client and
> server using the same locale.
>
>> > Also, with the GTK ui frontend of QEMU now, you'll get some translation
>> > of the user interface menu options thanks to GTK built-in translations,
>> > but the rest are still english, which is not very satisfactory either.
>>
>> As you noticed, this is not what happens, but I think this is the most
>> important point: If you translate something, translate all of it.
>> Mixed languages is worse than just English.
>>
>> Currently the split is that the GTK UI is completely translated, and
>> other parts (especially the monitor) isn't translated at all. This is
>> a split that is easy to understand and doesn't feel like mixed
>> languages.
Aside: in my private opinion, QEMU should've stayed out of the GUI
business.
>> If we want to extend it to the monitor, we need to translate all of the
>> monitor (including all error messages that could eventually be passed to
>> the monitor) in the same release. Sounds not impossible, but in this
>> case we really can't do just half of it as we usually do with our
>> conversions.
>
> Well, even if all the code was translated, we would never guarantee that
> all languages have 100% finished .po files. So incrementally updating the
> QEMU source to mark more strings is not that different from a case where
> all is marked but most translations are incomplete.
No different qualitatively (untranslated messages exist), but almost
certainly different quantitatively (how frequently do users see
untranslated messages?) Unless we make a serious effort to hunt down
and mark at least all the common messages.
However, internationalization takes more than just wrapping existing
strings in _(), then hand them off to an army of translators. At best,
that'll work tolerably for a few languages closely related to English
(assuming you tolerate bad grammar). If you don't believe me, check out
"A Localization Horror Story: It Could Happen To You"[*]. Quote:
[This] cautionary tale relates how an attempt at localization can
lead from programmer consternation, to program obfuscation, to a
need for sedation.
I doubt we're ready to attack this problem. Plenty of more urgent fish
to fry...
[*] http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod?#A_Localization_Horror_Story:_It_Could_Happen_To_You
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-06-03 7:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-02 12:56 [Qemu-devel] Translation of strings in QEMU w/ gettext ? Daniel P. Berrange
2015-06-02 13:20 ` Daniel P. Berrange
2015-06-02 14:34 ` Kevin Wolf
2015-06-02 14:40 ` Daniel P. Berrange
2015-06-03 7:28 ` Markus Armbruster
2015-06-02 14:53 ` Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.