[Freecats-Dev] Re: About your existing alpha/beta software

[Henri Chorand]

Hi Dan,

> Okay, I'm now registered in Savannah as durist.

Fine. You are enrolled by now ;-)


> > Considering the problems associated with Sun's attitude towards free
> > software, I believe that, ideally, we should try to avoid being too much
> > tied to their tools.
> >
> > As I see it, the best would be to use your plug-in for the translation
> > client's interface, and then, beyond, to rely on other, fully free and
fully
> > portable tools. We thought about Python because of this (and its ease of
> > 1° learning, 2° mixing with other code).
> >
> > This means you would split your project into two parts:
> > - The OO interface, which will interest all the translators in the team
and
> > discussion list. You can expect some feedback on it.
> > - The "under the hood" part, which may evolve separately, possibly be
> > gradually rewritten in another language...
>
> This is already how it's designed. Currently, the front-end is a set of
> OOo Basic macros, which talk to a SOAP server written in perl. The java
> piece is the web-services extension for OOo; it has nothing to do with
> the server. OpenOffice uses java as its primary extension language;
> there is no way to get around that.

This is mostly good news.
It would still work if we were to go along with Python, as the latter is, I
believe, accessible from a Java program (to be confirmed, the opposite is
OK).


> Is java going to be a problem for hosting it on Savannah?
> There's a bit on the registration page
>
(https://savannah.gnu.org/faq/?group_id=11&question=What_is_the_registration
_process.txt)
> that says:
>
> No dependencies to non free software

I think it's all right (not forbidden). As you probably know, the projects
admission criteria are quite strict on Savannah, which is also why I was
quite happy to see this project accepted at once.

I did a quick search with "Java" on:
http://savannah.nongnu.org/search/
and a number of projects appeared.
The proof is in the pudding.


> There is an INSTALL file in the distribution; but it's still fairly
complex.
>
> > As far as we can see it, fuzzy indexing and matching being all but an
exact
> > science, even a crude solution will be quite enough during prototyping
> > stages, and may evolve at its own path (adding "weird" (for Western
people)
> > languages is not forgotten).
>
> I think it also depends on how large a data set you're working with; a
> crude solution probably works okay until you have a really large
> translation memory. It seems to me that much of the value added by the
> better TM products is in editing convenience rather than linguistic
> cleverness. Currently my server uses a perl module called
> String::Similarity
> (http://search.cpan.org/~mlehmann/String-Similarity-0.02/Similarity.pm
> if you're interested in how it works); I have no idea how well it would
> scale.

I lack skills to discuss this further, but I'm confident we won't have too
many such problems, at least while we follow a strictly modular approach.


> I hope to have an improved version of OOxlate out soon; I'm adding a
> generic RDBMS backend (it will still work with plain files, but will
> easily scale up if you stick a real database behind it).

That's great. Flat files are OK, actually; the only issue would be fast
search (and indexing). I do hope you get a quick feed-back from Tim on this.

In the list's archive, you will find a few threads about our file formats.


Cheers,

Henri