At 22:52 09/06/2005, Alex Rousskov wrote:
If I understand your intent correctly, there are two rather different
problems here: programmer-language (keywords) neutrality and
content-language (data on the wire) neutrality. P/Sieve must be neutral to
the language of
the data on the wire, of course.
Yeap. This is the interest.
I doubt this group has enough energy and motivation to support the former;
P/Sieve programmers will most likely have to use English keywords. Said
that, it would be a trivial task (from technical point of view) to provide
alternative keyword codings so that non-english programmers feel more
confortable. For some reason, popular programming language standards do not
offer that kind of flexibility (AFAIK).
Some do as C (you define functions, etc.) for ASCII version. But you have
Arabic, Korean, Chinese development environments. Here the interest is to
possibly support 20.000 languages, if there is someone interested in each
and a way to write it :-) (far far less - but there is no reason why this
does not increase a lot with the current trend).
But the requirement is simple: keywords must be neutral to each other.
What, I think, is no problem. This only means no fancy idea like a keyword
being designed to match the begining of another keyword.
The way it should work is as follows:
(a) P/Sieve ASCII keyword ---> (b) numeric-universal-tag (unitag) ---> (c)
P/Sieve Cyrillic Keyword.
(a) is normal effort with the small provision above and an optional trigger
keyword.
(b) is a simple incrementation in the unitag system (will be documented in
a Draft soon) with the ASCII keyword description in English and French.
(c) made by Russian developers. togetgher with the Russian description and
How To.
jfc