[Freecats-Dev] Re: Free CATS - possible help

[David N. Welton]

Henri Chorand <address@hidden> writes:

> I'm sending a copy of this e-mail (a reply to your 2 last ones) over
> our mailing list, as it will interest all team members. Please feel
> free to subscribe even though you I know don't have time to code
> with us.

I think I am subscribed....

> What you say about Java confirms a some feeling I had, and I'll take
> your word for it.

If you don't care for Tcl, Python is another excellent choice.  Both
of them are very much "no b***s**t" languages - designed to get the job
done, not boost Sun's marketing.

> I even thought, could be implement an alpha version of our TM server
> with flat, .INI type files and simple string parsing functions, just
> to see something running ;-)

> > I would start playing around with a few different things, and see
> > what works best.

> Since (and following your advice) we chose Tcl/Tk as the main
> development team, I found out there are several, readily available
> components which might interest us. As you are a member of Apache
> Tcl project, do you have something to tell us about:
> http://xindice-xmlrpc.sourceforge.net/

Sure, you could do that... although the whole thing looks relatively
complex:-(

> By the way, I just noticed lots of new materials at:
> http://xml.apache.org/xindice/ I am right in assuming Apache Xindice
> is a Java project?

It is indeed.

> There is another, major design issue for which I would be glad to
> hear from you (and which we discussed at our first project team
> meeting last week).

> We know our document working format is going to be tagged. XML, and
> therefore Oasis' XLIFF, seems an obvious choice, but at the same time,
> in our little newbies' heads, we couldn't help raising a few issues:
> - XML specification is very "theoric" (writing a full-fledged XML
> parser is a hard task).
> - We can't help thinking about all existing HTML documents published
> so far, which structure is invalid from XML syntax's point of view.
> - We don't need/want to understand/alter the XML structure of
> translated documents - in fact, we want to be sure we preserve (and
> ignore) it.
> - Could a "dumb" approach be better than a "full-fledged" one?

Maybe.  And it might also have the *big* advantage that you could get
something working quickly, and then start worrying about how to make
it perfect.  That seems to be a good way to go for open source
projects.  People tend not to get interested if you are still in the
planning stages.

 > I mean, we don't need/want to translate documents the way an author
> would edit an XML document.  We first thought we would select and
> adapt an existing (free) XML editor so as to integrate it as Free
> CATS's editing document.  This implies we would have to deal to many
> complex already integrated features without which, in fact, we might
> be better off.  I tend to think that, for XML documents, we need to
> parse them in the MOST simple way, so as to identify:

> - actual text contents (to be translated)
> - "internal" formatting tags (to be played with, to some extent, but
> at the very least, we'll be able to accurately specify what we need)
> - "external" (XML structure) tags (to be left untouched).

I think you have a better picture in your mind of how this part works
than I do.

[ ... ]

>  > http://www.indexdata.dk/zebra/

> Oh, well... yes. Thanks a bunch, David.

> This might be THE answer.  (may I insert a comment for one of the
> team project members: BERTRAND, VA VOIR, C'EST POUR TOI
> !!!!!!!!!!!!!)

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/