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




From: Enda McDonnell <EndaMcD@alchemysoftware.ie>
To: xliff@lists.oasis-open.org
Date: Tue, 20 Jan 2004 15:49:11 -0000






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