Translation in Qt5
ossi at kde.org
Tue Jul 5 09:05:45 BST 2011
On Tue, Jul 05, 2011 at 12:57:27AM +0200, Chusslove Illich wrote:
> > [: Oswald Buddenhagen :]
> > because "everyone" is complaining about the extra contexts, including our
> > qml team.
> I would be interested at what the concrete complaints were.
- the class names cause many messages to be duplicated
- class names are not meaningful in qml
additionally, from the lupdate pov, the parsing of class names (and
namespaces) is unreliable in the face of #ifdefs and other preprocessor
> On that it depends whether those who complained would want to
sure they do - even if they don't know yet. the contexts were trying to
automate disambiguation. while they did a somewhat poor job with quite
some collateral damage, they still served a purpose.
> If they would, then @-markers do not automatically mean they would
> also want semantic markup. And if there is no markup, then @-markers
> are indeed pure convention, adding them equals adding one section to
correct. and in fact, nobody asked for semantic markup. so i asked you
why you added it, and what changed since.
> > kde libs continuing to have a separate i18n system will immediately cut
> > half of their value as qt addons.
> I do not understand this. [...]
> I could even conjecture an advantage in having two separate translation
> systems [...]
- it's yet another library. who wants to link kdecore (or maybe ki18n if
we went for such absurdly fine granularity) for "just" translations,
especially given that they are usually an afterthought?
- the ongoing basic feature duplication puts kde into a bad light
- it fragments the qt ecosystem regarding translations. the communities
translating qt and addons would have to deal with two systems.
- it deprives qt essentials themselves and addons & apps which want to
depend only on the essentials from having a reasonable translation
> Then you can market Qt translation system as seamlessly fitting with
> the translation industry practices, reducing costs of translation
> services -- I think this is by far the most important "feature" you
> can have.
"optimize for crap". no way. if somebody cares, he can make *that* an
More information about the kde-core-devel