[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]