MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xliff] Merge New Translation Request
Hi Enda, thank you for the screen capture.
I haven't used Catalyst yet but I've found a tool in okapi in sourceforge:
LeverageXLIFF. It merges current translation with new XLIFF file. It is a
simple xsl uses resname to match trans-unit in two files.
Now, I am considering the sequence of TM (translation memory) search.
(1)
Update ------ + ---------
| |
TM + ----> merged xliff
|
Current -----------------
versus
(2)
Update ------------
|
+ --- + ---> merged xliff
| |
Current ----------- TM
I think the difference is only the performance to apply the TM. Case (2)
only requirs to search for the segments which are new in the update,
because current should include TM in the initial preparation for
translation.
Thank you and Best Regards,
Eiju Akahane
Enda McDonnell <EndaMcD@alchemysoftware.ie> wrote on 2004/01/21 22:06:02:
> Hi,
> Yes, you are correct.
> You can perform a leverage at any stage during the process.
> If it is done pre-review, then leveraged strings will be marked
> translation-needs-review.
>
> Also, as you suggest, you can view the state information within the xliff
> editor.
> Please see attached screenshot for how strings are marked.
> This shot shows some strings which need review (eye symbol), and some
which
> are signed off (tick mark)
>
> Best regards,
> Enda
>
>
> -----Original Message-----
> From: Eiju Akahane [mailto:AKAHANE@jp.ibm.com]
> Sent: 20 January 2004 17:40
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Merge New Translation Request
>
>
>
>
>
>
> Hi Enda,
> Thank you for the detail steps how process work with Catalyst.
>
> We had problems at receiving a new translation request before completing
> the current translation. So, by using your example, the process can be
> implemented with Catalyst as follows.
>
> 1. Create first version of xliff file. Let's call it v1-en.xliff.
> <trans-unit resname='IDS_STRING1'>
> <source>Hello World</source>
> </trans-unit>
> 2. This file is then sent out for translation.
> 3. The xliff file comes back fully translated.
> 4. As they have been translated, but not accepted, the <target> elements
> will have a state='needs-review-translation'
> <trans-unit resname='IDS_STRING1'>
> <source>Hello World</source>
> <target state='translation-needs-review'>Bonjour</target>
> </trans-unit>
> 5. Now, while that is going on, a v2-en.xliff comes out.
> <trans-unit resname='IDS_STRING1'>
> <source>Hello World</source>
> </trans-unit>
> <trans-unit resname='IDS_STRING2'>
> <source>Hello World</source>
> </trans-unit>
> 6. v1-en.xliff is renamed to, say, v1-fr.xliff
> 7. Using Catalyst, it is possible to leverage this from v1-fr.xliff
> <trans-unit resname='IDS_STRING1'>
> <source>Hello World</source>
> <target state='needs-review-translation'>Bonjour</target>
> </trans-unit>
> <trans-unit resname='IDS_STRING2'>
> <source>Hello World</source>
> <target state='needs-review-translation'>Bonjour</target>
> </trans-unit>
>
> 8. Now, the translator continues translation. All
> 'needs-review-translation' will be checked by the translator before
> completing the work.
> 9. let's assume that the file is reviewed and all translations are
> accepted. The state attribute in the <target> elements will be changed
to
> state='signed-off' by Catalyst
>
> This process should work and translator might be able refer the state
> through the editor, Catalyst.
> I will be checking if this your process with XLIFF solve all multiple
> shipment issues we have.
>
> Thank you and Best Regards,
> Eiju
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]