"Daniel P. Berrange" <berra...@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
