[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: I18n in koffice scripts
From: Dag Andersen <danders () get2net ! dk>
Date: 2008-12-08 10:30:39
Message-ID: 200812081130.39515.danders () get2net ! dk
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Lørdag 06 december 2008 00:03:20 Chusslove Illich wrote:
> > [: Sebastian Sauer :]
> > Thanks for the details. Well, if I got it right, then I don't see the
> > problem with the #if(KDE) i18n() #else tr() #endif cause kde-applications
> > will use the i18n() always anyway while the tr() is only for Qt-only apps
> > outside of kde (so, no translations from our side needed anyway - means,
> > we just don't need to care and the tr() is only there to don't link
> > against kdelibs while providing a way for Qt-only apps to still use
> > translations).
>
> You got it right, but, in my opinion, this is a very poor state of things.
>
> If code is pure-Qt, then it should use native Qt translation facilities. If
> the code was made pure-Qt in the first place, that was in order for it to
> be usable outside of KDE context, and these days usable normally means
> translated to various languages too. And this should be achieved without
> duplication of effort, on either programmer or translator side. A pure Qt
> client should be able to "just use" that code, and automatically have
> translations made by KDE translators. Conversely, hooking into KDE
> translation system if the code is used in a KDE app, is profoundly wrong;
> the i18n workings of a piece of code should not depend on its client.
>
> I guess that we historically went this route because it was easy: very
> little tweaking to message extraction to extract from Qt code too, no need
> to define, request and write any special guidelines for i18n infrastructure
> for pure-Qt code in KDE repository. But this should be fixed in the future.
> (For translators, we would also have to establish Qt Linguist -> POT -> PO
> -> Qt Linguist chain.)
>
> And until this happens, we shouldn't aggravate the situation by leaking
> KDE- isms into translation of pure-Qt code. At present, at least any
> outside client can take current translation files and make use of them
> through own, custom effort. And while some KDE-isms are technically
> leakable to pure-Qt code translations (but deliberately prevented), other
> are not even that (Transcript).
>
> Erm... to the point :) Please no #if(KDE) i18n() #else tr() #endif. Either
> use i18n() for code strictly dependent on kdelibs, or tr() if that is not
> the case. And within mixed KDE-pure-Qt body of code, always extract pure-Qt
> parts into separate message catalog, i.e. everything which is using tr()
> directly or under the hood.
I see three different types of runtime dependencies for scripts:
1) Not dependent on Kross
Is it conceivable/possible that a "plain" script is written wo using any qt ui
and is independent of Kross? Can they be run via Kross at all?
Translation must then use script language native tranlation facilities eg _()
for python.
2) Dependent on Kross
A script that does not depend on a koffice app, eg a viewer of info (files,
internet...)
An example is the onlinehelp.py script in kword. (It doesn't have any ui
though, so no need for translation)
Scripts of this type could also be usefull for non-koffice apps, even qt only
and should use tr() for translation.
3) Dependent on koffice app.
Most of of the current scripts in koffice depends on one or more koffice app.
I think this will be the norm for scripts shipped with koffice.
I don't see why we should not use i18n for these. It would need somewhere to
implement i18n and if not in Kross, either "KdeKross" (new class: Kross + i18n
to make it available to other kde apps), or in KoKross.
What do you say?
Hmmm. a good question is if tr() is enough, afaics it provides plural but no
arguments. Is that right?
--
Mvh.
Dag Andersen
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'Sans Serif'; font-size:10pt; \
font-weight:400; font-style:normal;">On Lørdag 06 december 2008 00:03:20 Chusslove \
Illich wrote:<br> > > [: Sebastian Sauer :]<br>
> > Thanks for the details. Well, if I got it right, then I don't see the<br>
> > problem with the #if(KDE) i18n() #else tr() #endif cause \
kde-applications<br> > > will use the i18n() always anyway while the tr() is \
only for Qt-only apps<br> > > outside of kde (so, no translations from our side \
needed anyway - means,<br> > > we just don't need to care and the tr() is only \
there to don't link<br> > > against kdelibs while providing a way for Qt-only \
apps to still use<br> > > translations).<br>
><br>
> You got it right, but, in my opinion, this is a very poor state of things.<br>
><br>
> If code is pure-Qt, then it should use native Qt translation facilities. If<br>
> the code was made pure-Qt in the first place, that was in order for it to<br>
> be usable outside of KDE context, and these days usable normally means<br>
> translated to various languages too. And this should be achieved without<br>
> duplication of effort, on either programmer or translator side. A pure Qt<br>
> client should be able to "just use" that code, and automatically have<br>
> translations made by KDE translators. Conversely, hooking into KDE<br>
> translation system if the code is used in a KDE app, is profoundly wrong;<br>
> the i18n workings of a piece of code should not depend on its client.<br>
><br>
> I guess that we historically went this route because it was easy: very<br>
> little tweaking to message extraction to extract from Qt code too, no need<br>
> to define, request and write any special guidelines for i18n infrastructure<br>
> for pure-Qt code in KDE repository. But this should be fixed in the future.<br>
> (For translators, we would also have to establish Qt Linguist -> POT -> \
PO<br> > -> Qt Linguist chain.)<br>
><br>
> And until this happens, we shouldn't aggravate the situation by leaking<br>
> KDE- isms into translation of pure-Qt code. At present, at least any<br>
> outside client can take current translation files and make use of them<br>
> through own, custom effort. And while some KDE-isms are technically<br>
> leakable to pure-Qt code translations (but deliberately prevented), other<br>
> are not even that (Transcript).<br>
><br>
> Erm... to the point :) Please no #if(KDE) i18n() #else tr() #endif. Either<br>
> use i18n() for code strictly dependent on kdelibs, or tr() if that is not<br>
> the case. And within mixed KDE-pure-Qt body of code, always extract pure-Qt<br>
> parts into separate message catalog, i.e. everything which is using tr()<br>
> directly or under the hood.<br>
I see three different types of runtime dependencies for scripts:<br>
1) Not dependent on Kross<br>
Is it conceivable/possible that a "plain" script is written wo using any qt ui and is \
independent of Kross? Can they be run via Kross at all?<br> Translation must then use \
script language native tranlation facilities eg _() for python.<br> 2) Dependent on \
Kross<br> A script that does not depend on a koffice app, eg a viewer of info (files, \
internet...)<br> An example is the onlinehelp.py script in kword. (It doesn't have \
any ui though, so no need for translation)<br> Scripts of this type could also be \
usefull for non-koffice apps, even qt only and should use tr() for translation.<br> \
3) Dependent on koffice app.<br> Most of of the current scripts in koffice depends on \
one or more koffice app.<br> I think this will be the norm for scripts shipped with \
koffice.<br> I don't see why we should not use i18n for these. It would need \
somewhere to implement i18n and if not in Kross, either "KdeKross" (new class: Kross \
+ i18n to make it available to other kde apps), or in KoKross.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>What do you say?<br> Hmmm. a good question is if tr() is \
enough, afaics it provides plural but no arguments. Is that \
right?<br>
-- <br>
Mvh.<br>
Dag Andersen</p></body></html>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic