[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-05 8:05:45
Message-ID: 20110705080545.GA12109 () ugly ! local
[Download RAW message or body]

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
magic.

> 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. 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
> documentation.
> 
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
  system.

> 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
addon.
[prev in list] [next in list] [prev in thread] [next in thread]