[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Translation in Qt5
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2011-07-02 18:16:34
Message-ID: 20110702181634.GA30686 () ugly ! local
[Download RAW message or body]

On Sat, Jul 02, 2011 at 02:51:54PM +0200, Chusslove Illich wrote:
> * PO has to be natively supported.
>
it already is.

> By this I do not mean merely use of MO files at runtime,
>
given that MO is not a subset of PO, this is pretty self-evident. :P

> but the whole process:

> xgettext for extraction,
>
why would that matter? anything fundamentally wrong with lupdate?

> msgmerge for merging,
>
you already can do that.

> msgfmt for compiling to MO
>
i don't see any difference to lrelease here ...

> The real advantage instead is in the format and the process; and also
> tool support on translators' side.
> 
how is the process fundamentally different from the linguist toolchain?
why would the format matter for anything other than the tool support?

> 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.
> 
presumably you mean "cheap" => no plurals. i wouldn't know other
shortcomings.

> Now, if the unified system would support PO, then supporting Qt Linguist as
> well would be dead weight from my point of view.
>
kind of. but then, qt tries to have no external tool dependencies, because
they are a hassle on anything except linux. i'm also not sure how the
requirement for using gpl'd tools would resonate with some of the
proprietary qt customers.

> The translation scripting requirement may be more taxing than at first
> sight.

> For one, translation scripting absolutely requires a public
> "translated text" class (current KLocalizedString).
> 
that sounds like no biggie. i don't see much point in a QStringFormatter
unrelated to translations - it just seemed like a generalization bonus.

> 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?
>
uhm, sorry? a simple setter function "heavy"?

> And then comes the JavaScript wrapper in the background, file format
> elements, language-specific scripting libraries, etc.
> 
that doesn't matter as long as these are not link-time dependencies of
qtcore. the point is that non-users should not be penalized by the mere
presence of the feature.

> > 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()
>
the use case is adjusting the format to available size, which is a
very real problem on small devices.
i couldn't care less about tools which cannot be fixed to properly
support it.
i'm not sure how it could be of any significance for translators. they
are dealing with printf formats outside the kde world all the time.
usually one can simply consider the formats as atoms.

> (note that the latter has neither multi-argument variants nor
> double-expansion problems).
> 
the % operator is just a shorthand for subs(). together with an
implicit QString conversion, it would fix some (minor) problems by
removing the need for a wrapper function like i18n, which:
- has an absurd number of overloads
- has an arbitrary limit on argument count
- cannot be used for complex formats (though obviously i'm trying to
  make that argument void)

some random differences between gettext() and tr():
- tr() uses %n instead of the first generic integer parameter for
  identifying the plural form. i like it that way, because it's more
  explicit.
- tr() has no plural support for the source language. this means that
  the messages are by definition degraded to elaborate ids. this has
  some theoretical advantages:
  - it's not specific to english grammar. this is of no concern for
    international projects, but a lot of smaller/local projects (usually
    proprietary ones) does not use english.
  - as a "translation" is necessary anyway, typos & style issues in the
    source language can be fixed even during string freeze.
  in practice, the need for an additional translation is somewhat
  annoying (and consequently neither qt nor creator have one).
  i'm yet to be convinced which approach is better.


lupdate somewhat recently gained support for purely informative comments
(//:, equivalent to //gettext:). these are also used for transmitting
meta data (message ids, etc.). i kind of dislike this format, because it
is detached from the actual c++ grammar. so i'm considering a dummy
argument to qTr() instead:

QLocalizedString qTr(const char *ctxt, const char *msg, const char *meta, int n = -1);
QLocalizedString qTr(const char *ctxt, const char *msg, int n = -1);
QLocalizedString qTr(const char *msg, int n = -1);

qTr("@action:button Mail", "&Send",
    "= qtn_mail_compose_send\n"
    "~ width=32\n"
    "The 'Send' button in the 'Compose Email' dialog");

i left the n parameter in the prototype to denote the need for numerus
forms. the alternative would be adding qTrN(), but that's ugly. otoh, it
would be necessary for Q_TR_NOOP anyway (fwiw, this is currently simply
missing in qt).
[prev in list] [next in list] [prev in thread] [next in thread]