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,
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
Enda McDonnell <EndaMcD@alchemysoftware.ie> wrote on 2004/01/21 00:49:11:
> 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
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.
Xliff_With_Status.jpg
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]