--nextPart1440790.xqhdgJsynj
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
>> [: Chusslove Illich :]
>> I think that it is not good to decide for translators what is non-
>> translatable. Because it is easy to go too far and declare non-
>> translatable something that someone will want to translate. Instead it is
>> better to *inform* translators what things in text are, so they can make
>> decisions.[...]
>
> [: Thomas Eschenbacher :]
> No, I disagree here. There are cases where strings must never be
> translated, and it is not obvious to any translator, just from looking at
> the pot file as it has no context information.
Yes, there are such cases. And a perfect author could perfectly prevent from
translation only such cases. However, perfect translator could also
perfectly realize which cases are not to be translated. An imperfect author
will sometimes prevent translation of something that should be translated,
and an imperfect translator will sometimes translate that which should not
be translated.
So this may look like a question of balance, but in this particular
environment, it isn't. Because, just like most of maintainers of KDE
programs, most of translators of KDE programs are hobbyists. And it is bad
for hobbyst's motivation to prevent him from doing the best possible job
because he might mess up.
Instead, first it should be observed in practice that translators mess up
too much. When that is observed, the first course of action is to inform
translators better. When informing also doesn't prevent too many failures,
next thing is automation to not accept work that doesn't pass mandatory
checks. But never to prevent the best possible job in the first place.
> There are two cases we need to address here:
>
> 1) Some messages are just too trivial and produce only useless work load
> for translators. Example: I have a translation table with ASCII-to-URL
> encoding. [...]
Such messages produce only trivial work for translators. It's pretty much
not worth bothering about doing anything with them.
> 2) The more relevant case is the description of the commands. Kwave has
> scripting capabilities, like a simple "programming language". If you take
> a keyword of this language you *must* *never* translate that [...]
Agreed, and like a reader would be, KDE translators are usually also good at
realizing this. Frequently too conservative in fact, not touching that which
they should because they are not sure if it can be translated.
>> Though in this case (Docbook extraction with xml2po) there is also no
>> facility to inform translators...
>
> Then we need a solution that intercepts before, I vote for adding a
> feature to xml2pot.
Yes, that would definitely be great. It is not an invasive thing, so if
you'd like to give it a shot, I don't think anyone will complain. And also
here I volunteer to test it on my side.
> The ideal option for me would be having an _attribute_ like translate=3D"=
no",
> but as far as I understand this would require a different dtd...
But this... no way :) This is something that is typically available e.g. in
approaches coming from commercial translation (XLIFF etc). And using it
almost invariably results in preventing translators from doing the best
possible job. Besides the obvious error of not exposing for translation what
should be exposed, a more disguised effect is that of reducing the global
context for translators (when the excluded text is not at all seen in the
translation file).
=46or a familiar example, consider this message:
% cmake [source directory] -DWITH_MP3=3DON [other options...]
The author has decided to exclude it from translation, although many
translators will want to translate the segments "source directory" and
"other options...".
Instead, there is a very simple rule that authors should follow: if the
reader can see it, the translator must be able to see it and edit it. And of
course it can be only good to add extra information for the translator.
>> If I were in your place, I would simply do nothing (no special marking,
>> no post-processing), and wait and check how often translators get it
>> wrong. [...]
>
> That's no real option to me, too much work, sorry. [...]
I'm not sure: did you actually had this experience, from KDE translators? If
you did, you could see what to do about xmp2pot to provide info for
translators, and I will write the appropriate checks for our weekly running
translation checker. These checks are advisory, so if after that you still
have too much work, then we can see how to make the checks mandatory
(block-on-fail).
=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)
--nextPart1440790.xqhdgJsynj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEABECAAYFAlTvCz0ACgkQMSGXgigGr3HSHwCfWLhtrG2USFj80A2KXOCgCckb
D4oAn3wvOdIJB5bETZcPCxxErYypuyCK
=FPol
-----END PGP SIGNATURE-----
--nextPart1440790.xqhdgJsynj--