Finalized proposal for changes to i18n in KF5

[Chusslove Illich]

> [: Oswald Buddenhagen :]
> of course, it would be even better if you strived for submission to qt-
> project, if at all realistic (for now probably an add-on, but definitely
> under cla). otherwise you'll see the same effect every other useful lgpl'd
> qt framework sees sonner or later: it gets re-implemented (if the effort
> is deemed acceptable by an interested party).

I'm not opposed to some additional bureaucracy in order to make the
framework more accessible to potential users. But I'd have to see what it
actually means, and what could be the tradeoff.

As for another party reimplementating the framework, I don't see what factor
is that. (Hypothetically speaking, though, I don't see it happening: if
someone wants Gettext-based translation in Qt code but not through Ki18n, I
expect he will, well, use Gettext directly.)

> [...] make klocalizedstring.h #undef TRANSLATION_CATALOG at the end (may
> need to use a macro indirection to ensure that the macro is fully expanded
> already at definition time (see QT_STRINGIFY in qt 5)).

I looked, but couldn't figure out how to use it in this context.

>>> [: Chusslove Illich :]
>>> #define i18n(...) i18nd(TRANSLATION_CATALOG, __VA_ARGS__)
>>
>> [: David Faure :]
>> Is this portable to all compilers supported by KDE?
>
> [: Oswald Buddenhagen :]
> i wonder. see Q_COMPILER_VARIADIC_MACROS in qt5/qtbase/src/corelib/global/
> qcompilerdetection.h

Could someone parse it for us and make a set-intersection with supported
compilers for KF5? :)

> [a number of spotted documentation glitches]

Great!

> i find the 5.0-superscripts in the tables way too noisy. alternative
> ideas: - use a separate column - just default to 5.0, and thus defer the
> problem (possibly indefinitely) strictly speaking, the 5.0 is a lie
> anyway. ^^ in qt, we actually left in the 4.x version markers, to play in
> line with the "mostly source-compatible" theme.

I'd definitelly like to have the version markers visible for all elements.
For example, so that there is no uncertainty whether a marker was forgotten
or not.

I struggled with how to present it, and in particular thought that a
separate colon is an overkill. Maybe have the superscript yet smaller and a
bit dimmer?

What the initial version should be, I'll wait for someone else to decide.

> and as usual for native-only-in-slavic speakers, some "the"s are missing.
> i was too lame to record their locations. ^^

I've given up and put a pox on them.

(I did toy with another idea though: compute the statistical average of
the's-per-word for a given class of texts, and then pepper my text
proportionally.)

> your headers consistently have a space after function names. the kdelibs
> coding style says something different ...

I'm putting a space after the function name when the function is declared or
defined, as opposed to being called. Grudgingly, I'll get rid of them.

> the "extern"s in front of the ki18n* declarations seem pointless and
> untypical to me.

Actually I've no idea what these exports are/were for. They were added in
e51d7bfb with note "fix build failure for MSVC++'2005", and I didn't feel
compelled to inquire.

> i don't like the recommendation for extracted vs. disambiguating comments
> (and closed-source authors will typically do the exact opposite anyway).
> wouldn't it be sufficient for disambiguiation to strongly recommend
> consistent use of user interface markers, and thus allow all comments to
> be extracted? the matter of flagging changes is merely tooling-related.

Yes, but tooling decisions are related to PO convention and workflow.
There'd be awful lot of tooling to modify, and modify by adding options and
not changeing the default behavior. There would also be no practical purpose
to having both types of contexts, unless there was a significant difference
between them.

And in KDE code this recommendation is actually the tradition. Even if
because it maybe wasn't given much second thought once contexts were
available...

> one thing i noticed while looking through catalogs is that it often would
> be useful to be able to declare some kind of hierarchical comments, so
> that a particular comment could apply to a whole group of strings, without
> needing to replicate it, or relying on the translators' ability to see the
> pattern themselves (which is a pipe dream, especially if only some strings
> in an existing group changed). i suspect that this may turn out "a bit"
> hard to implement without hacking gettext (and the .po format) ...

The nicety of not having to manually replicate comments and contexts in
hierarchical situations, would have to be balanced by introducing yet more
i18n-related syntax to source files. This also means that drive-by i18n
fixers would have to pay more attention, and that code i18n checking tools
would have to be smarter. The usual story of simplicity and robustness vs.
capability and efficiency.

I don't think anything in PO files should change in this case, simply make a
proper split of information between of #. and msgctxt. It is the extraction
tool, xgettext, that would need changes.

-- 
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-core-devel/attachments/20130105/b16e7391/attachment.sig>