Postfixing .po that come from Qt::tr() with a _qt.po

Chusslove Illich caslav.ilic at gmx.net
Thu Apr 10 22:18:15 UTC 2014


> [: Albert Astals Cid :]
> Hi, do you think it makes sense to use that postfix?
>
> We are using this currently for stuff like marble and trojita so our
> translators know they can't use advanced stuff like JS scripting for the
> translations.

For this particular reason, the better solution is to make sure all PO
messages from i18n() calls get the kde-format flag. This is in fact how it
should have been all along, since consistency of argument placeholders is
always checked for at runtime. E.g. if the source text has no placeholders
but translation contains %1 (can be unfuzzying error), without the format
flat nothing will signal this error.

However, since tr() messages don't enforce placeholder consistency (no
placeholder in source means also no .arg(), so stray placecholder in
translation is not syntax error), they cannot get qt-format flag
unconditionally. So positive identification ("this is Qt message" as opposed
to "this is not KI18n message") is not possible by format flag alone. And
positive identification is sometimes useful, e.g. for applying Qt markup
checks. From this standpoint, it would be nice to add the postfix.

In summary, I'd go for the postfix. If there were an enormous amount of tr()
-derived PO files, I'd think harder, but given they are expected in low-tier
frameworks and few elsewhere, not.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140411/8b782a18/attachment-0001.sig>


More information about the Kde-frameworks-devel mailing list