Re: Mistranslations in gtk

[Christian Rose <menthos gnome org>]

fre 2005-01-14 klockan 22:20 +0100 skrev Pablo Saratxaga:
> > > Yes, it would; but please, use the already existing convention
> > > used in KDE instead of reinventing the wheel!
> > 
> > This is implemented in glib: if you don't like that behaviour, you
> > should probably report it as a bug/RFE.
> 
> I think indeed that it would be better if a common marking could be
> settled (just like having a common format for *.desktop files has
> huge advantages).
> Was that implemented long ago? is it still time to change it?

It was implemented in glib more than a year ago (see
http://bugzilla.gnome.org/show_bug.cgi?id=97556), and it was provided in
the eel library (and used by applications using eel) long before that.
Also, it had been discussed on this list umpteen times.


> > In Gnome project, we commonly rely on updates to
> > GNU gettext instead of introducing hacks in PO messages themselves
> 
> Well, in this case, gettext still doesn't provide that (a glib
> function implementing it is as much a hack in PO message than
> a libqtsomething implementing it)
> 
> > (look at how KDE handles ngettext-style features).
> 
> I indeed prefer it the ngettext way, as it relies on a lower level
> (and so, larger) base.
> 
> But in the case of the context information/disambiguation, there isn't
> any gettext-level solution; and existing solutions all work the same:
> adding an extra text with some sort of delimiter and stripping at
> display time what is before the delimiter.
> The bad thing is there is no standardization at all on the
> delimiters to use.

Agreed, and unfortunately I think we'll only see some real
standardization when gettext finally supports this (is there some work
still going on in that area?).

In fact, according to
http://bugzilla.gnome.org/show_bug.cgi?id=97556#c21, the
"context|message" style seems to have originated from a proposal in the
gettext manual, so perhaps it's KDE that is doing the odd thing here.

Personally, I find the KDE style of marking context hardly readable. The
glib style of course relies on "|" being uncommon in messages, but that
is an assumption that appears to be almost always true in practice.


> The advantage of adopting the KDE-style is that it is largely in
> use, and has been, AFAIK, the first to standardize it on a large
> scale (for all KDE (and maybe Qt?) programs).
> On Gnome there was some time ago, ad-hoc solutions when needed,
> with absolutely no standardization.
> 
> If something is standardized at glib level it's good news (I thought
> it was just at gnome level), but I find it unfortunate not to have
> choose a way similar to an already largely used similar solution.

When this was implemented in eel (and then later in glib), I suspect
there was an expectation that since the gettext manual
(http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC151) recommended the "context|message" style, this would turn out to be the de facto style that implementations would use.

And perhaps it still is that way, with KDE being the odd child here.
Anyway, I don't see much of a point with reverting to a style that is
much less readable for translators, and which doesn't even to be the
recommended style according to gettext.


> > I myself would prefer if the same processing was done on translation
> > as is done on original strings, because translators would need no
> > explanation at all in such cases, and the risk of them mistranslating
> > it would be minimal (only if they added another context marker, i.e. "|").
> > 
> > I.e. translating "file|prefix" to either of "file|blahblah"
> > (untranslated context), "foo|blahblah" (translated context) or
> > "blahblah" (without context) would work correctly.  I'm interested in
> > a rationale for choosing current behaviour in glib:

Indeed, this is a big bug, the glib implementation should be robust
enough to allow for a translated context marker in the translation, or
the | and everything before it being completely missing from the
translation.
Danilo, can you file a glib bug report? Otherwise I'll do it tomorrow,
if I remember it.


Christian