Re: [Texmacs-dev] TeXmacs server

[Joris van der Hoeven]

On Sat, Jun 03, 2006 at 04:35:40PM +0200, Alvaro Tejero Cantero wrote:
> >As a conclusion, I think that one needs to build dictionaries which
> >map trees into translated trees, where the source trees are as small
> >as possible (paragraphs, or even sentences).
> 
> Yes, this is definitely the way to go. I thought some time ago that
> there had to be a way to write multilingual documents and keep them in
> sync. At the time, it seemed to me that one would enclose different
> language correspondents of one "unit" (e.g. one paragraph) in an
> environment (e.g. \spanish) and then selectively make visible the
> source and target language (english, spanish) for translation and only
> the target language for reading.

Yes, I was thinking in a similar direction. I definitely think that
the translation process can be improved a lot by including extra facilities
in the editor. For instance, find the first non-translated piece after
the cursor. Show originals, show translations, show both, etc.

> In principle the typesetter is not slowed down by all the content
> which is only optionally displayed and not currently visible, right?

You are right: the typesetter does not spend any time on the invisible stuff.

> >At any rate, I temporarily gave up the improvement of the translation 
> >process, because I fear it to be quite tricky and time consuming.
> >If I had one month of time, then I could do a very nice job.
> >But unfortunately, I don't.
> 
> It looks like all the infrastructure for the above mentioned "simple"
> translation approach, which overlaps with what is needed for revisions
> and annotations to a certain extent would be doable in scheme, just by
> defining the right environments.

Yes, things seem relatively easy. But working them out nicely and in detail
takes a lot of time, I fear. At any rate, I think that it is good to
concentrate on the basic infra-structure first: a TeXmacs server,
where translations can directly be registered and maintained,
as well as a CVS for TeXmacs documents (and in particular all documentation).

Notice also that the necessary tools can in principle be written by
someone else, because they are quite independent froml the rest of TeXmacs.

> Regarding the wiki source format issue, I think that it would be
> valuable to have a compatibility mode which would work by writing html
> (therefore being compatible with current wiki engines) and ship the
> mathematics either as a png or as MathML. Trying to have wikis remain
> as much as possible browser-writable is a worthwile goal...

Yes, but I temporarily give up. Having an Html compatability mode means
having an Html style, which means having done a lot of basic work
on the style language layer. I plan to do that, but this is one of
the last major fundamental thing which still needs to be done in TeXmacs
(apart from reorganizing the linking business and the typesetter).

One may temporarily convert between TeXmacs and Html/Xhtml/MathML,
but it is not reliable to build a read/write wiki on top of that.
Of course, it would be possible, if someone took the time to define
a clean sublanguage in which a one-to-one correspondance does exist
and writes the necessary tools to enforce this sublanguage.
But I have no time for this.

My main aim is that we have a good Wiki for TeXmacs itself,
available from within TeXmacs itself. At the moment, we have several
nice tutorials, which are hard to classify and include. Having them
on this Wiki will make it easier for people to learn TeXmacs.