[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KDE4 (Translation Scripting)
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-04-22 15:32:39
Message-ID: 200504221732.42197.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Stephan Kulow :]
> Most translators seem not even able to call check_po_files before
> checking

This is more an organizatorial than capability issue, but I agree that it 
does tell something about commitment. Then again, most is not all 
(hopefully :), and scripting will not force itself upon uninterested.

> [...] not talking about adding syntax errors on a language even I have
> problems getting right on first shot.

If there is a syntax error in the script, it only means that ordinary, 
non-scripted translation will be used; it will neither render complete PO 
file useless, nor leave user without translation of any sort for given 
message. Though, the msgstr itself must still be valid in context of PO 
file, but that's nothing new.

On the other hand, I suppose that people who will make scripts, will also 
know better and be more inclined to assure that their scripts work.

> I think I said it before: I do not think that programming lisp can be
> expected from translators.

Not all translators would have to script, one man per team who is capable 
of that (the spec-ops guy) is more than enough: scripting will be needed 
in rare instances, *but* these rare instances will typically be very 
prominent.

As for Lisp (Scheme) being too complicated for this purpose, I don't think 
that is really true. Nobody forces you to program Lisp in Lisp :) 
Seriously, years back and straight out of high school (where we were 
taught Pascal and C), I needed to program in AutoCAD's AutoLISP. The 
scripts I made were, in effect, pure procedural; if that is what you want, 
Lisp enables you to do so. In the examples I presented, I never used any 
functional programming or even recursion.

The only strange thing about Lisp is its prefix syntax, but that is about 
all the syntax you need.

> [...] But a general interpreter in user given input (and translations
> are nothing else as you can put translation files in ~/.kde) is
> something that is _at least_ from a security aspect inacceptable.

I was afraid of security issues, true. How about this (I am prowling in the 
dark here): if the program is running under effective UID root and real 
UID *not* root, scripting engine doesn't wake up at all?

Sorry if I am bothering you with trivia, but I would also like to know what 
are the other aspects?

I should also mention that if, hypothetically, we would implement scripting 
engine and far too many problems accumulate, it would be very easy to rip 
its guts out (i.e. without destroying binary compatibility). Than we are 
left only with an empty shell of i18n functional class, resulting in 
negligible performance hit compared to current i18n functions.

> BTW: if you really believe you need scripting, then define some very
> limited language and implement the interpreter yourself.

Actually that was my first shot (and I posted the idea on this list, just a 
concept, in December 2003). But I went into direction that crossed way 
with Scheme, and Guile was waiting at that crossroad, so...

> And one more suggestion: that limited language should not be a
> functional language

Something simple, eh? How about Logo? Ooops... :)

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]