i18n in Frameworks, the lightweight version
caslav.ilic at gmx.net
Tue Dec 6 20:14:48 UTC 2011
> [: Aaron J. Seigo :]
> interesting; i can't locate the config key to use by looking at the code.
> where might i find this, as it could be a nice improvement for Plasma
> Active 2.
This will do it:
But note that the scripting extension is loaded only when the first scripted
translation comes up. If that doesn't happen anywhere for you, you won't see
any change with this switch. To really check the effect, you could for
example run the fuzzy clock applet in German.
> assuming this doesn't greatly deteriorate the quality of translations and
> that it remains compatible with existing translations, then this could go
> into the mobile build profile.
The system is such that the translator must supply the ordinary translation
along with the scripted one. So there is no incompatibility if scripting is
turned off, and quality deteriorates to being as good as the best non-KDE
stuff out there.
> so if the optimization can be made without side effects and someone is
> willing to do the work, how can we justify saying "no, please don't
> improve the code"?
I'm not seeing it as an optimization in the larger picture; I'm not seeing
it making things worse either[*], but that only leads me to "don't fix
what's not broken". Where resources are tight as you describe, disabling
scripting per above should be much more meaningful.
[*] As for performance, I would need hard numbers on relevant cases. To make
engine. This means that one would have to port to QtScript already to be
able to actually factor performance into the final decision.
By the way, you mentioned 10 MB saving without KJS/KHTML, but translation
systems needs only libkjs, which takes 0.8 MiB on my machine (from distro
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Kde-frameworks-devel