Re: Mistranslations in gtk

[danilo gnome org (Danilo Åegan)]

Hi Matthias,

Today at 2:47, Matthias Clasen wrote:

>    There is only one more comment to be said.  The wrapper function
> above requires that the translations strings are not enlengthened
> themselves.  This is only logical.  There is no need to disambiguate
> the strings (since they are never used as keys for a search) and one
> also saves quite some memory and disk space by doing this.

I agree: this is logical from programmer's point of view.  But it's
not logical from translator's point of view.  You yourself complain
about translators keeping the context marker, either translated or
not: you aren't claiming that translators have no sense of logic, are
you? ;)

Anyway, this isn't going this way to work without gettext getting
support to tag such messages appropriately for translators.

> I don't consider this optimization to be a bug. It also has the benefit
> that you can use the '|' character without problems in translations.

Unless you introduce comments for all the messages that use context
marking, you'll have mistranslations pop-up occasionally.  You may not
consider it a bug, but it will cause problems for you and for everyone
else.

"Strip up-to first | from translation" implementation would work for
most ways translators would ever think of translating context-marked
message in.

msgid "here|there" would be correctly translated if translator used
either of:

  "here-translation|there-translation"
  "here|there-translation"
  "there-translation"

The big benefit is that you don't have to explain anything, and don't
have to wait for gettext to be improved.

The problem would come up only in the case of messages such as:

  "here|there|goes"

where translators would have to include context themselves.  Such
messages would be *very* rare, and if translators adopted practice of
always including context marker in translation (whether translated or
not), then they would work as usual.

> One improvement that I think would be possible on the gettext level 
> would be if xgettext could add comments to the extracted messages 
> depending on the macro that they were extracted from. That would allow
> us to have a "strip everything up to (and including) the first '|'"
> comment to all prefixed messages without putting tons of 
> /* translators: ... */ comments in the source code.

Actually, I think it would be enough to extend --flag xgettext option
to support something like:

  xgettext --flag=Q_:1:strip-context

which will output messages into PO files such as:

#: ../source.c:45
#, strip-context, c-format
msgid "blah|hello %s"
msgstr ""

This is what I referred to in my original reply: sorry for not being
clear enough.  I believe --flag currently supports only
language-format style flags, such as "c-format", "no-python-format",
etc.  So, it would be as simple as removing checks for valid flags.

Cheers,
Danilo