--nextPart1440689.N1iLS5L6yp
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

>> [: John Layt :]
>> * New QStringFormatter to solve tr() args problem. Community to code? [I
>> don't understand the problem or solution here :-)]
>
> [: Oswald Buddenhagen :]
> the problems to solve:
> [...]

Given the general direction of these localization-related messages, should I
assume that the desired outcome for translation system too would be to unify
KDE's and Qt's systems into one? If so, that may be a though goal, because
I'd have the following two hard requirements:

* PO has to be natively supported. By this I do not mean merely use of MO
files at runtime, but the whole process: xgettext for extraction, msgmerge
for merging, msgfmt for compiling to MO (or pretty complete clones of
these).

* Translation scripting has to be available.

The PO requirement is because it is the superior solution compared to
anything else out there. The funny thing is that the runtime part of it
(glibc access functions for MO files) is the least significant; I wouldn't
mind, and in fact I would want, that one written anew. The real advantage
instead is in the format and the process; and also tool support on
translators' side.

Short note on two other "contenders".

I consider Qt Linguist (format, l* tools, process) to be the nearest
equivalent to PO, but not better in any important aspect, and worse in some.
Even when independent tool support is not counted.

XLIFF is totally out of the question. The primary problem XLIFF tries to
solve does not exist in free software, and it does not even try to address
things that PO (or Qt Linguist for that matter) include since forever. This
is because XLIFF was built around observations of commercial translation
environments, which are very different from those we have.

Now, if the unified system would support PO, then supporting Qt Linguist as
well would be dead weight from my point of view. I wouldn't want to
(co)maintain such a mix, and would be annoyed whenever one would block
something for the other. A satisfactory resolution would be to deprecate Qt
Linguist (again: format, tools, process), let it stand as it is and fix bugs
only, and commit development to a pure-PO solution -- which may be asking a
bit too much, right? :)

The translation scripting requirement may be more taxing than at first
sight. Especially since you said that you would accept it only if it
wouldn't be "too heavy code-wise" (though until now I thought you wouldn't
accept it regardless, so this is improvement). For one, translation
scripting absolutely requires a public "translated text" class (current
KLocalizedString). Argument substitution has to be done by it, rather then
by a generic string class (QString/QFormattedString); it is also needed for
dynamic context feature (see API doc of KLocalizedString for this one). I
could imagine that this alone counts "heavy code-wise" -- does it? And then
comes the JavaScript wrapper in the background, file format elements,
language-specific scripting libraries, etc.

>> [: John Layt :]
>> * Semantic markup wanted: copy KUIT from KDE, inline markup do rewrite to
>> Chusselove's revised design.
>
> [: Oswald Buddenhagen :]
> [...]
> - for the inline markup, chusslove gave me a list with 10-15 items when i
> asked "what would you do differently if you could do KUIT again?". half of
> it is all greek to me, so somebody actually familiar with the code and
> spec needs to take up on that.

May sound curious, but I consider this not to be an essential element of the
translation system, unlike PO and scripting. I could live without it. In
particular because it has rought edges, both in detail and in concept.

I really should do two things with respect to markup. One is to convert that
list of problems that I gave you into a non-all-greek text, since all those
problems still stand as they are. The other is to write a text about what I
would consider a "perfect text translation library"; I mention this here,
because most of the nowhere-seen-yet features proposed in that text would be
about markup.

> for advanced formatting, i'm envisioning the syntax %[12.34h]1, i.e.,
> sprintf-like options in brackets.

I'm somehow converging to the opinion that this would not be good for
translated text (I'm not saying anything about general string handling). It
seems to me it just serves to confuse translators and translation support
tools, while providing no real advantage over an external formatting
facility, like current QString::arg() or KLocalizedString::subs() (note that
the latter has neither multi-argument variants nor double-expansion
problems).

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart1440689.N1iLS5L6yp
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk4PFGoACgkQMSGXgigGr3EKogCgj3tSNW5Cq9BhQTZUsqA8VgvY
3jcAn1zOwbf8DRl0lq69yni4qEHPNxQu
=e3Xp
-----END PGP SIGNATURE-----

--nextPart1440689.N1iLS5L6yp--