On Tue, Jul 05, 2011 at 11:04:41AM +0200, Chusslove Illich wrote: > [: Oswald Buddenhagen :] > > - the class names cause many messages to be duplicated > > This is exactly the reason I was afraid someone had put out :) It basically > reveals that "they" care zero about context. It shows you... > > >> On that it depends whether those who complained would want to compensate. > > > > sure they do - even if they don't know yet. the contexts were trying to > > automate disambiguation.[...] > > ...that "they" weren't seriously thinking about disambiguation at all. > that's not entirely fair or even accurate. for one, i was talking about duplicated messages which positively do *not* need disambiguation (otherwise the argument would be bogus in the first place). second, it isn't too surprising that many people didn't think about alternatives, given that the automatic contexts are there, even if they do a rather poor job at disambiguating in a semantically meaningful way.
> I really would like it to be a library on its own, precisely so that I > could use it and recommend it out of KDE (as in KDE project/community) > and Qt apps. > that won't fly. the current library's qt integration both improves its usefulness and makes its implementation much more lightweight. > In fact, the hardest thing about that library is designing how it > should interface and behave. > yes, exactly. this is a typical case for shared specification, not shared code. > > - the ongoing basic feature duplication puts kde into a bad light > > There is already Linguist and raw Gettext. That already makes for > duplication, unless Qt switches to raw Gettext, > i mean duplication within the qt ecosystem. it would be a somewhat poor outcome for kde's qt-addon-ification effort if it doesn't manage to upstream something as core as i18n. > > - it fragments the qt ecosystem regarding translations. the > > communities translating qt and addons would have to deal with two > > systems. > > Not entirely. [...] I will personally go in and hack it to do the > TS->PO->TS roundabout, so that KDE (as in KDE Translation Project) > translators do not feel Linguist workflow. > that's only half the problem. one also needs to contribute translations to qt upstream, and within the legal framework of the qt contribution model, there is no way around the translators dealing with whatever system qt chooses to use. fwiw, there have been thoughts of detaching the "qt translation project" from the qt contribution model. not sure about the licensing model; whether lgpl-only would be acceptable. > > - it deprives qt essentials themselves and addons & apps which want to > > depend only on the essentials from having a reasonable translation system. > > Linguist is a *reasonable* translation system. > ok, let's amend that. it deprives (apps & libs using only) qt essentials from being being really well translatable. the dualism you are suggesting makes no sense even for qtcore itself - it has both high-quality community translations and crappy commercial translations out of need for nokia devices. consequently we need a system which serves both target groups, without noteworthy compromises on either side. > It is better than anything other than raw Gettext/PO. When TS->PO->TS > roundabout is present, they become equivalent[1]. > > [1] Just please add per-file plural formulas. They can be optional, > with fallback to hardcoded default if missing. > i already did that. in fact, (i think) i fixed all problems you pointed out in your last review round. and just for fun, the PO->TS->PO roundtrip should be lossless as well. in theory, you can directly open PO files in linguist (in practice, it often does not work due to TS having no representation for PO's #~|). the one thing that is not compatible are the plurals. during the TS->PO coversion, i simply duplicate msgid into msgid_plural (i wonder whether an empty string would work instead?). on the way back, i drop identical plural sources, while differing ones are stored in an extension field (which is displayed by linguist, but is otherwise meaningless to the system). on top of that, the plural formulas are inherently incompatible (linguist adds and preserves gettext ones, but cannot use them in any meaningful way). so while using PO is feasible for transporting qt translations, it isn't really native and thus would be a suboptimal choice for a default format given the current state of affairs. it's all about determining priorities and making choices now.