OmegaT - multiplatform CAT tool

JC Helary wrote on 03/03/2006 03:28 PM:

> Could it be possible to have someone make a relatively brief summary  
> of this thread because unless one has read all the mails over 2 lists  
> it is actually quite hard to follow.

This thread is the culmination of two threads, on which started as 
OpenOffice bashing on L4T, and one which started right there, which 
concerned sentence segmentation based uncleaned file translation.

The L4T thread is basically:
* OpenOffice can't handle this or that
* OpenOffice can do this and that
* then:  Whether OOo can do Trados uncleaned files
* then:  Methods for dealing with Trados uncleaned files
* then... turns out that it may be possible to actually program a Java 
solution for uncleaned files which work directly with the OOo document 
at source code level.
* then discussing various ways of doing this

The OmTDev thread is basically:
* Henry, JC and I to-ing and fro-ing about OmT's current method of 
dealing with Trados uncleaned files using OOo as a document format, 
using OmT's sentence segmentation.

To summarise, Henry thinks he can program OmT so that it can deal with 
Trados uncleaned OOo files by inserting styles and the necessary stuff 
directly into the source code of the OOo file.  His original offer 
related only to scenario in which the translator receives a 
non-presegmented file which the client but delivers a Trados uncleaned 
file back to the client.  I'm trying to figure out ways to broaden the 
possible support for Trados uncleaned files, if possible.

Samuel

JC Helary wrote:
>
> In fact, just like what happened to "my" documentation thread yesterday,
> it looks like we are going in a number of directions that may not be all
> equally explored because "we" don't seem to take enough time to make a
> summary of the thing, especially for people who never had to work with
> Trados related files but who could nonetheless provide comments based on
> their experience.
> 
I keep an archive of all important related messages. I summarise them
before I actually start anything. (So I don't do any unnecessary work if
I never start it.)

Henry

Thanks Samual, it is much clearer now :)

> To summarise, Henry thinks he can program OmT so that it can deal  
> with Trados uncleaned OOo files by inserting styles and the  
> necessary stuff directly into the source code of the OOo file.

I would say, like Sonja, that doing that from inside OmegaT is  
missing the fact that a simple external utility in Java (like the 2  
we already have online) to produce such files for later parsing in  
OmegaT would seem easier to implement/test/develop/use.

Now I am not a Trados client so I don't really understand all the  
issues discussed here, but let's say we have a bilingual file parser  
(the XLIFF thing Martin is working on :) It seems to me we'd need  
only a(n external) filter (a la OLT) to have PO/Trados/etc support  
within the XLIFF support ? Am I wrong ?

JC

JC Helary wrote on 03/03/2006 04:11 PM:

> Thanks Samual, it is much clearer now :)

My pleasure... I only hope Henry agrees with my summary.

> Now I am not a Trados client so I don't really understand all the  
> issues discussed here, but let's say we have a bilingual file parser  
> (the XLIFF thing Martin is working on :) It seems to me we'd need  
> only a(n external) filter (a la OLT) to have PO/Trados/etc support  
> within the XLIFF support ? Am I wrong ?

That went completely over my head, so I have no idea.

Just to restate my position, my original comments in these thread did 
not imply that we *should* create such a feature in OmT (Henry indicated 
the possibility thereof quite voluntarily).  My original threads in 
various mailing lists concerned attempts to support Trados uncleaned 
files using OmegaT's and OOo's *existing* features.  Along the way I 
discovered that OOo's Find/Replace feature is a dismal failure AFAICS 
and that it would not be possible to tweak my existing methods to 
utilise OOo only.

I'm all in favour of an OmegaT suite of tools which include the main 
program and several extra programs that does various things in a useful 
manner.  If the extra programs can be plugins, great.  If they can be 
written in a language which presumably the user has installed already 
(ie Java and OOo macro), then great.  Remember, not all translators are 
computer literate.

Samuel

JC Helary wrote:
>
> Now I am not a Trados client so I don't really understand all the issues
> discussed here, but let's say we have a bilingual file parser (the XLIFF
> thing Martin is working on :) It seems to me we'd need only a(n
> external) filter (a la OLT) to have PO/Trados/etc support within the
> XLIFF support ? Am I wrong ?
> 
If we have full XLIFF support, then I agree a Trados->XLIFF->Trados
converter util would be better. Although OmegaT could call the util
directly :)

Henry

And just as I write these lines, we see Martin checking in ;)

How nice !

JC :)

On 2006/03/03, at 23:34, Henry Pijffers wrote:

> JC Helary wrote:
>>
>> Now I am not a Trados client so I don't really understand all the  
>> issues
>> discussed here, but let's say we have a bilingual file parser (the  
>> XLIFF
>> thing Martin is working on :) It seems to me we'd need only a(n
>> external) filter (a la OLT) to have PO/Trados/etc support within the
>> XLIFF support ? Am I wrong ?
>>
> If we have full XLIFF support, then I agree a Trados->XLIFF->Trados
> converter util would be better. Although OmegaT could call the util
> directly :)
>
> Henry

I don't believe my name has ever been Martin ;)

_Henry_

JC Helary wrote:
> And just as I write these lines, we see Martin checking in ;)
> 
> How nice !
> 
> JC :)
> 
> On 2006/03/03, at 23:34, Henry Pijffers wrote:
> 
>> JC Helary wrote:
>>>
>>> Now I am not a Trados client so I don't really understand all the issues
>>> discussed here, but let's say we have a bilingual file parser (the XLIFF
>>> thing Martin is working on :) It seems to me we'd need only a(n
>>> external) filter (a la OLT) to have PO/Trados/etc support within the
>>> XLIFF support ? Am I wrong ?
>>>
>> If we have full XLIFF support, then I agree a Trados->XLIFF->Trados
>> converter util would be better. Although OmegaT could call the util
>> directly :)
>>
>> Henry