texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] TeXmacs server


From: Henri Lesourd
Subject: Re: [Texmacs-dev] TeXmacs server
Date: Sat, 03 Jun 2006 18:00:29 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Joris van der Hoeven wrote:

On Fri, Jun 02, 2006 at 08:13:26AM -0500, Offray Vladimir Luna Cárdenas wrote:
Is nice to see the TeXmacs Wiki idea.

The wiki is definitely the way to go. I strongly
agree that it is an interesting direction.

None of the Wikis I know have a nice WYSIWYG/WYSIWYM to enable mathematical writing.

I met people some months ago who use LaTeX in their
wiki language : this way, they can very easily generate
pages containing mathematical output (the .ps output of
LaTeX being translated as an image).

¿How you envision that the effort of TeXmacs Wiki could be integrated with previous/other wiki engines?

I don't. We discussed that with Alvaro a long time ago.
The point is that if you want to be able to edit the pages
with another editor than TeXmacs, then using the TeXmacs format
will cause a lot of problems. When using a non-TeXmacs format,
then it has to be very clean, so that the converters are 100% safe.
But this means that a lot of functionality will be lost.

This point is a blocking point, because one of the main
features of wikis is of course that one can access them
with a simple browser.

On the other hand, for people who already regularly use
the wiki, the use of TeXmacs for accessing and editing
the website would be better.

Therefore, a nice approach for a TeXmacs-editable Wiki
would be an approach where the Wiki remains editable
in any browser, given that in such a situation, the
performance/features should degrade gracefully (i.e.,
inside a Browser, the user is limited to a well-defined
formula language, which is inputted in a non-wysiwyg
way). But in any case, whether a page in the Wiki has
been edited in a Browser or inside TeXmacs, everything
remains always editable from within TeXmacs (but
perhaps not from inside the Browser : the editable
view of the page could give only access to the parts
or the document which are sufficiently simple).

On the other hand, if someone has the courage to develop a reliable
format which can be used both by TeXmacs and other Wiki engines,
then it will not be hard to add it.

If it is to be used by other Wiki engines, I'm afraid
that hacking in their code is required...

I managed to build such dictionaries for the existing translations,
but the success is heavily dependent on the way things were translated.
For the Spanish documentation, I managed to recover about 2/3 of the mapping.
For the German translations, almost nothing, because the translator wanted
to do too good a job by rephrasing things, adding examples, etc.
which makes it hard to obtain a good correspondance automatically.

Instead of a general solution (which, as a matter
of fact, amounts to be able to translate unconstrained
natural language, and is thus rather irrealistic), the
solution used by SGML people (e.g., for documentation
in the industry) is to have an SGML DTD where all
the parts of the documents are multilingual. For
example :
[[
<DOCUMENT ID=DOC1>
<TITLE>
 <PARAGRAPH ID=PAR1>
   <DATA LANG=EN>Hello</SENTENCE>
   <DATA LANG=FR>Bonjour</SENTENCE>
   <DATA LANG=DE>Guten tag</SENTENCE>
 </PARAGRAPH>
</TITLE>

<INTRODUCTION>
 <PARAGRAPH ID=PAR2>
   <DATA LANG=DE>Ich mochte sagen dass diese dokument
                 ist sehr shon</DATA>
   <DATA LANG=SP>Hasta la vista, los documentos este
                 muy agradable</DATA>
 </PARAGRAPH>
</INTRODUCTION>

etc.
</DOCUMENT>
]]

Observe that in the document above, the paragraph PAR1
has (yet) no Spanish translation, while in the paragraph
PAR2, the French and the English translation are missing.

Observe also that the translations are not always
completely litteral translations.

When browsing the document in a (theoretical) editor
which understands the SGML dialect above, different
translators can switch the current language, and
observe that some translations are missing. Therefore,
a Spanish/English-speaking person could decide to
complete the document by adding the Spanish translation
of PAR1, and the English translation of PAR2.

As one can see, this system allows for a multiuser,
incremental translation of the documentation.

This completely obviates the problem that Joris was
describing, namely, recovering only 2/3 of the Spanish
translation, and nothing in the German one.

To summarize, this approach is the only approach known
which, on the one hand, allows for a convenient editing
and **maintaining** of multilingual documents, and which,
on the other hand, gives a sufficiently complete freedom
to the translators.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]