From kde-core-devel Sat Jul 02 18:16:34 2011 From: Oswald Buddenhagen Date: Sat, 02 Jul 2011 18:16:34 +0000 To: kde-core-devel Subject: Re: Translation in Qt5 Message-Id: <20110702181634.GA30686 () ugly ! local> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=130963062502901 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).