Keith J. Schultz wrote:
I am aware that it is not a trivial task.
I have stated before that the "english" is to be the default and
what is far more important the actually use language!!
This would keep backward compatibility, in other words
inorder to use "legacy" files is a trivial task.
IF one wanted to use a localized language the would have to load a
list of translations for commands and units, etc and use a set command.
This approach would also allow for the switching between localized versions.
Where the code could be injected to provide the functionality is as you
mentioned important.
I think I can safely assume that the tex code is somewhat archaic and not easy
to patch.
Though I have not look at the sources since the 80s.
Keith, I don't see enough in your answer to enable me to understand
how you propose to resolve what seem to me to be very serious
problems of semantic ambiguity. Let me give a simple example,
using a fictitious language (Mekon) that use the basic latin character set.
Mekon defines the following translations :
\efg = \def
\emph = \centerline
\foe = \end
\joqvu = \input
File-1 contains :
%!Markup-language = Mekon
\joqvu File-2
\emph {Ifmmp xpsme !}
\foe
File-2 contains :
%!Markup-language = Mekon
\efg \emph #1{}
\end
When the processing engine encounters \emph at line 3 of File-1,
should it translate \emph into \centerline, as required by the
translation rules for Mekon, or should it leave it untranslated
so that it can reference the definition of \emph that occurs
at line 2 of File-2 ?
And when that same processing engine is called upon to process
File-2, should it translate \emph as \centerline, so that it
is \centerline that is being defined, or should it leave it
untranslated and therefore it is \emph that is being defined ?
In other words, can we, with 100% precision, define in which
contexts strings should be translated and in which contexts they
should not, bearing in mind the fundamental ability of TeX
programs to change the meaning of virtually everything on
the fly ?
Philip Taylor
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
