From kde-i18n-doc Fri Apr 22 15:32:39 2005 From: Chusslove Illich Date: Fri, 22 Apr 2005 15:32:39 +0000 To: kde-i18n-doc Subject: Re: KDE4 (Translation Scripting) Message-Id: <200504221732.42197.caslav.ilic () gmx ! net> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=111418430216504 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart3580595.2z4HcVhU3W" --nextPart3580595.2z4HcVhU3W Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > [: 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=20 does tell something about commitment. Then again, most is not all=20 (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,=20 non-scripted translation will be used; it will neither render complete PO=20 file useless, nor leave user without translation of any sort for given=20 message. Though, the msgstr itself must still be valid in context of PO=20 file, but that's nothing new. On the other hand, I suppose that people who will make scripts, will also=20 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=20 of that (the spec-ops guy) is more than enough: scripting will be needed=20 in rare instances, *but* these rare instances will typically be very=20 prominent. As for Lisp (Scheme) being too complicated for this purpose, I don't think= =20 that is really true. Nobody forces you to program Lisp in Lisp :)=20 Seriously, years back and straight out of high school (where we were=20 taught Pascal and C), I needed to program in AutoCAD's AutoLISP. The=20 scripts I made were, in effect, pure procedural; if that is what you want,= =20 Lisp enables you to do so. In the examples I presented, I never used any=20 functional programming or even recursion. The only strange thing about Lisp is its prefix syntax, but that is about=20 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= =20 dark here): if the program is running under effective UID root and real=20 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= =20 are the other aspects? I should also mention that if, hypothetically, we would implement scripting= =20 engine and far too many problems accumulate, it would be very easy to rip=20 its guts out (i.e. without destroying binary compatibility). Than we are=20 left only with an empty shell of i18n functional class, resulting in=20 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= =20 concept, in December 2003). But I went into direction that crossed way=20 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... :) =2D-=20 Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8= =D1=9B) Serbian KDE translation team --nextPart3580595.2z4HcVhU3W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCaRkaMSGXgigGr3ERAtZ+AKCXxPjlXTYMMLa6xnYRs+w/fA8PIwCgq4KC SJVGBBq99RouknjpwAsGMMU= =7Mtq -----END PGP SIGNATURE----- --nextPart3580595.2z4HcVhU3W--