[ omegat-Feature Requests-1651257 ] XLIFF: read from <source>, <write> to target

[SourceForge.net <no...@so...>]

Feature Requests item #1651257, was opened at 2007-02-03 15:28
Message generated for change (Comment added) made by henry_pijffers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=520350&aid=1651257&group_id=68187

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: File filters
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Didier Briel (didierbr)
Assigned to: Nobody/Anonymous (nobody)
Summary: XLIFF: read from <source>, <write> to target

Initial Comment:
The current XLIFF filter is reading and writing to <target>, which only works with the documents generated by Okapi for OmegaT.

The XLIFF filter should read from <source>, and writing the translation to <target>, creating this tag if it doesn't already exist.

Didier

----------------------------------------------------------------------

>Comment By: Henry Pijffers (henry_pijffers)
Date: 2007-02-23 15:08

Message:
Logged In: YES 
user_id=545103
Originator: NO

Note that the version attribute only specifies the XLIFF version. So if
you create the target yourself, you just use the XLIFF version you support.

----------------------------------------------------------------------

Comment By: Didier Briel (didierbr)
Date: 2007-02-23 14:42

Message:
Logged In: YES 
user_id=1343245
Originator: YES

<<I didn't realise this RFE concerned only Okapi's XLIFF files.>>

It doesn't.
Reading from <target> is just temporary, to have quickly something
compatible with Okapi.

<<IMO this RFE is unimplementable>>

Then, how do you think other XLIFF editors work?
Reading from source and writing to target is the normal way (read the
XLIFF specifications).

<<Not OmegaT nor any other program (except the client's own stupid
program)
can guess what additional attributes the client expects the <target>
section to have (if we're talking about a generic XLIFF file).>>

There's no guessing.
Either <target> exists, and it is left strictly unchanged (except the
translatable text, of course).
Or <target> doesn’t exist, and <source> (including all its attributes)
is copied as <target>.

Didier


----------------------------------------------------------------------

Comment By: Samuel Murray (leuce)
Date: 2007-02-23 14:26

Message:
Logged In: YES 
user_id=168045
Originator: NO


I didn't realise this RFE concerned only Okapi's XLIFF files.

<< Then also have a subsection on how to create the <target>s by copying
the <source>es. >>

< Would it be necessary if this RFE is implemented? >

IMO this RFE is unimplementable (unless we're talking specifically about
the Okapi XLIFF file).

Not OmegaT nor any other program (except the client's own stupid program)
can guess what additional attributes the client expects the <target>
section to have (if we're talking about a generic XLIFF file).

----------------------------------------------------------------------

Comment By: Didier Briel (didierbr)
Date: 2007-02-23 13:27

Message:
Logged In: YES 
user_id=1343245
Originator: YES

<<Then also have a subsection on how to create the
<target>s by copying the <source>es.>>

Would it be necessary if this RFE is implemented?

<<or would it be smart enough to know to make it
version 1 instead?>>

Yes (provided the target tag already exists, of course).
OmegaT only changes the content of translatable text.

Didier




----------------------------------------------------------------------

Comment By: Jean-Christophe Helary (brandelune)
Date: 2007-02-23 13:24

Message:
Logged In: YES 
user_id=915082
Originator: NO

Samuel, keep in mind that the current XLIFF filter is only an Okapi-XLIFF
filter. It is not yet intended to support generic XLIFF.

----------------------------------------------------------------------

Comment By: Samuel Murray (leuce)
Date: 2007-02-23 13:12

Message:
Logged In: YES 
user_id=168045
Originator: NO

Yes, but remember that a client's XLIFF might contain additional stuff
that OmegaT won't include, then.  Rather, I'd say, teach users how to do
regex find/replace in jEdit by having a comprehensive section about it in
the OmegaT user manual.  Then also have a subsection on how to create the
<target>s by copying the <source>es.

For example, the Proz.com XLIFF file has this in it:

<trans-unit id="m_mab">
<source xml:lang="eng" version="3">Track Abuse</source>
<target xml:lang="fra" version="1">Recherche des abus</target>
</trans-unit>

How would OmegaT handle the "version" information then?  Would OmegaT make
the FRA text also version 3, or would it be smart enough to know to make it
version 1 instead?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=520350&aid=1651257&group_id=68187