Finalized proposal for changes to i18n in KF5

[Chusslove Illich]

>> [: Chusslove Illich :]
>> I'm not opposed to some additional bureaucracy in order to make the
>> framework more accessible to potential users. [...]
>
> [: Oswald Buddenhagen :]
> [...] i'd hate it to see my thoroughly engineered code being displaced by
> a (possibly even slightly inferior) competitor just because i can't
> compete on licensing compatibility terms.

One step back: who exactly would find KDE Frameworks licensing terms non-
workable? I can't say I care what a party for which none of the options at
http://techbase.kde.org/Policies/Licensing_Policy works will do. By "more
accessible" I meant in technical and organizational terms.

> [: Oswald Buddenhagen :]
>   #define RESOLVE_TRANSLATION_CATALOG(c) (c)
>   #define i18n(...) i18nd(RESOLVE_TRANSLATION_CATALOG(TRANSLATION_CATALOG), __VA_ARGS__)
>   #undef RESOLVE_TRANSLATION_CATALOG
>   #undef TRANSLATION_CATALOG
>
> i'm not sure this actually works ...

Doesn't...

> also, getting people into the habit of defaulting to comments (paired with
> consistent use of @markers) makes it less likely that they put an epic
> into a disambiguation when they really meant to put it into a comment
> (which is easier to edit and produces leaner catalogs).

I don't see that advantage. In fact, PO comments unfortunately have no
multi-line semantics so the editor must present them as is, while it can
rewrap PO contexts according to user's set width.

> [: Oswald Buddenhagen :]
> 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 [...]
>
>> [: Chusslove Illich :]
>> I don't think anything in PO files should change in this case, simply
>> make a proper split of information between of #. and msgctxt. [...]
>
> [: Oswald Buddenhagen :]
> that suggests that you would duplicate the extracted comment into all msgs
> it's supposed to apply to. of course that's easiest (it doesn't need
> special presentation support) and wholly sufficient for typical uses
> (e.g., comment 120 strings with "keyboard key name"), but would look
> "funny" in other cases (e.g., and epic which describes the correlation of
> three messages).

Right. But doing something more clever on this side introduces the same
tradeoff as for programmers, only worse due to much more diverse tooling on
translator side.

The current handling of this situation is to put the long comment/context on
one message, and a short comment/context pointing to it on other messages.
Pointing is of course ad-hoc, but one could easily adopt an intuitive
convention here.

I really insist on keeping the translation file format syntax-low and
convention-rich, i.e. highly human-readabable and forgiving on tools. This
is because the problem domain looks simple, so other than the basic need for
id-value pairs, two people will propose three sets of additional features.
This will result in a mountain of syntax of not always clear semantics,
which humans will find hard to look at, and tools hard to fully conform to,
denying the intended advantages.

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