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 Eiju,
Firstly, welcome to the group.
Also, best of luck Mark with what you are moving on to, it's been a pleasure
working with you.
Regarding your query Eiju, what you mention is something that is supported
by xliff. It is process dependant and can be implemented simply using the
state attribute of the <target> element.
I will explain how such a process is implemented in Catalyst.
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, let's assume that the file is reviewed and all translations are
accepted
6. The state attribute in the <target> elements will be changed to
state='signed-off' by Catalyst
<trans-unit resname='IDS_STRING1'>
<source>Hello World</source>
<target state='signed-off'>Bonjour</target>
</trans-unit>
7. The file is renamed to, say, v1-fr.xliff
8. 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>
9. This has new strings, removed strings and some changed strings when
compared with v1-en.xliff
10. Using Catalyst, it is possible to leverage this from v1-en.xliff
New strings will be left untranslated with state='needs-l10n'
Changed strings will be left untranslated with state='needs-l10n'
<trans-unit resname='IDS_STRING1'>
<source>Hello World</source>
<target state='signed-off'>Bonjour</target>
</trans-unit>
<trans-unit resname='IDS_STRING2'>
<source>Hello World</source>
<target state='translation-needs-review'>Bonjour</target>
</trans-unit>
11. Strings with valid translations will be either
state='signed-off' - occurs where the resname matched between
v2-en.xliff and v1-en.xliff
state='translation-needs-review' - occurs where the resname did not
matched between v2-en.xliff and v1-en.xliff
This is typical behaviour in Catalyst when performing a leverage.
When IDs are available and match, then extra information such as memos and
status flags are leveraged along with text.
Where IDs do not match, the translations are pulled across, but the status
is set to translation-needs-review.
If your file is further manually translated, it is always possible to tell
which strings have been previously accepted and which are newly edited by
the state attribute of target. Only when all strings reviewed again and all
marked as signed-off is the distinction lost. Even then, xliff supports a
number of ways to store this extra information should it be required.
The state-qualifier attribute could be used to keep more detailed
information.
Also the <phase> element within target could be used to store exactly
which part of the process applied changes to the target.
Best regards,
Enda
-----Original Message-----
From: Eiju Akahane [mailto:AKAHANE@jp.ibm.com]
Sent: 20 January 2004 12:18
To: xliff@lists.oasis-open.org
Subject: [xliff] Merge New Translation Request
Hello, I am joining the mailing list of TC from IBM. I would like to solve
one of our problems by introducing XLIFF...
In our process, translators sometimes receive updated source text (second
shipment) before completing the translation of the previous source (first
shipment). The translator requires some manual process to merge the
translation for the updated request. It is done by extracting memory from
first shipment and apply the extracted memory (not-reviewed-yet because it
is a middle of translation) along with the older (reviewed-quality) memory
to the second shipment. After applying these memories, we cannot
distinguish the segment which has not-reviewed-yet from the segment which
has reviewed-quality translation.
Above is one of the problem we have in supporting the updated translation
we call it as multiple shipments.
Does XLIFF can work with the multiple shipments?
I think XLIFF can store translation state as an attribute of <target>
element such as "needs-review-translation." If we extract this information
into a memory and apply to second shipment, we can store the same state at
<target> or state-qualifier of <alt-trans>. We might be able to
distinguish the segment which include not-reviewed-yet translation from
reviewed ones in a XLIFF editor.
Are there any other ways to merge translations in XLIFF?
Thank you and Best Regards,
Eiju Akahane, Yamato Software Lab., Software Group, IBM
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xliff/members/leave_workgroup.p
hp.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]