Someone: Please do consider what happens if I, on an
American OC system open a German OC stack in your
proposal.
Alain: Have you taken into consideration HyperCard's
Translator interface? It sits in between the script
editor and the disk. It pre-processes the scripts that
are read from disk, and post-processes scripts just
before they are written to disk. It's the feature that
allows HyperCard to support more than one language in
the ScriptEditor (e.g. set the language to German)
Someone: 1) Unless you had the german interpreter
installed on your system you would be unable to open
the stack.
Alain: The above Translator requires a language
resource for each language supported.
Someone: The stack would keep all it's original
code...
Alain: That's the beauty of the Translator. All
scripts are stored on disk in a generic form that can
be used with any interpreter. It is only when the
script is edited that language-specific substitutions
come into play.
Someone: 2) If you had the American decompiler
installed on your system, the German stack would get
decompiled into its American equivalent because the
decompiler deals with the bytecodes not the German.
Alain: Yes, this is how HC's Translator works too.
Someone: 3) We use a language translation product and
then repair the scripts afterward.
Alain: The language translation facilites currently
available through the Web do a fair translation job.
Someone: I suggest using option two and then running
the variable names and comments through a modified
option 3. Then we get whatever we get.
Alain: We can integrate these language-translation
programs into OpenKard if they are open source like we
are, or add some Web-oriented syntax to OpenKard so as
to implement some translation bots.
Someone: All of this of course happens AFTER we get a
couple decent engines to justify the need.
Alain: One engine fits all human languages because the
interpreter only deals with the generic OK bytecodes.
Someone: The bytecodes are not transparently cross
platform, but why couldn't we create a cross platform
superset for purposes of translation to other
platforms?
Alain: Excellent idea!
Someone: The OC byte codes would only appear when you
save the stack file to the hard disk as a stack..
Alain: Exactly!
Someone: ..(as opposed to platform specific
executable) for the purposes of making the stack file
itself cross platform. This adds a layer of
abstraction and leaves us with the ability to support
multiple languages.
Alain: Good (design) thinking.
Someone: The first major hurdle is standardizing on
the OC bytecode language as that will define our
limitations.
Alain: Yup. Can a non-programmer help in this matter?
Someone: The next is implementing our first
interpreter.
Alain: Already in motion.
Someone: ... one xTalk may actually have more features
than another, however both will be subsets of the OC
bytecodes.
Alain: Sounds good.
Someone: If we also implemented the concept of "style
themes" for the editor, we could get around the
annoyance of having our code reformatted for us. The
capitalization, and code structure would be defined by
the "theme" which could be individually tailored. The
programmer could then use whatever "theme" was their
favorite and never have worry about annoying someone
else because that other person would just load the
code into their own "theme".
Alain: Another wonderful idea. I like it!
Alain: PS: Sorry about the anonynous assignment of
names of the two listers that I was replying to. I
completely lost track of who said what. So, when in
doubt ..
Alain: PS: If there is interest in HC's Translator, I
can provide all the technical details of this
little-known HyperCard feature.
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
