XLIFF for TALIS 2024 - Audit Analysis

Major problems in XLIFF Data_XLIFF_Export_v1_2_20220331142431053.xlf:

I suppose you have some constraints that limit what you can do, so not all my feedback might be relevant for the work you do to generate the XLIFF file, some of it might apply to how text is previously handled in the online tool from which you export your source content. In other words, the problem is always not in your XLIFF per se, but in the content from where the translatable text must be extracted to put in the XLIFF. Hopefully we can find a solution to each problem.

Also, it seems that partly what makes your task of creating these XLIFF files more complex is that you're extracting two text versions in parallel. I suppose that's because the XLIFF is being created after the translation has been done elsewhere. I think this would be much easier if the XLIFF files were created before translation, translation was done in the XLIFF file and then that translated XLIFF file was sent to revision/verification.

In fact, I have also run a segment translation consistency analysis on the XLIFF file and I have found quite 1-to-many and many-to-1 inconsistencies. Below you will find a link to QA report Data_XLIFF_Export_deu-DEU_forVF_20220401_VF08rpt.xlsx, which flags them. I think all those inconsistencies are easily avoidable by translating in a CAT tool. But that's a translation quality issue, not a problem in the XLIFF file per se.

Let's look at the technical problems in the XLIFF file:

Mixture of source languages

The file is not purely or always bilingual: it contains some German text as source language (approximately the second half of the file, I think from unit 8871 onward), whereas the source language of the XLIFF file is supposed to be English (as per attribute source-language="en").

<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xliff:document:1.2 xliff-core-1.2-transitional.xsd">
  <file datatype="xml" source-language="en" target-language="de" original="global">
    <body>
<!-- source text in English -->
      <trans-unit id="2862" xml:space="preserve" approved="yes">
        <source>About You</source>
        <target>Über Sie</target>
        <note>TQ - G01_de-DE</note>
      </trans-unit>
(...)
<!-- source text in German -->
      <trans-unit id="8871" xml:space="preserve" approved="yes">
        <source>Über Sie</source>
        <target>Über Sie</target>
        <note>EXL_TQ - G14_de-DE</note>
      </trans-unit>
      <trans-unit id="8872" xml:space="preserve" approved="yes">
        <source>G14. Wie viele Jahre (einschließlich des laufenden Schuljahres) unterrichten Sie schon Viertklässler:innen?</source>
        <target>G14. Wie viele Jahre (einschließlich des laufenden Schuljahres) unterrichten Sie schon Viertklässler:innen?</target>
        <note>EXL_TQ - G14_de-DE</note>
      </trans-unit>
(...)      

Having source or target text in a language other than the one(s) specified in the file complicates the task for users and PMs involved as well as technically, since a number of settings (tokenization, abbreviations, etc.) are language-specific, they will not for, say, German if English is expected.

Proposed solutions

I don't know what causes this, but if you have a mixture of languages in the source content, I would advise to label each of your content blocks so that languages are clearly identified, which should allow you to extract only English as the source language for this file. Not an ideal solution but as an alternative you could also label all translation units that have German text in the source node with attribute translate="no", that way they will not appear in the translation tool (OmegaT, in our case).

If those segments with source text in German must be extracted because it's a matter of two tasks, i.e. review of a English-German translation and (review of) a German-German adaptation, I would strongly advise to create two separate XLIFF files for that: one with English as source language and another one with German as source language.

No segmentation between sentences

This is the most serious problem I see in the file. Some translation units contain more than one sentence, for example:

<trans-unit id="8007" xml:space="preserve" approved="yes">
  <source>The following does not concern all of science instruction, but rather sciences instruction. 
Questions S1 and S4 concern the natural science instruction for students in the fourth grade in the TIMSS class. 

S1. A. Is science taught mainly as a separate subject (i.e., not integrated with other subjects) to the students in this class?</source>
  <target>Im Folgenden geht es nicht um den gesamten Sachunterricht, sondern nur um den naturwissenschaftlichen Sachunterricht.
Die Fragen S1 bis S4 beziehen sich auf den naturwissenschaftlichen Sachunterricht für die Schüler:innen der vierten Klassenstufe in der TIMSS-Klasse.

S1. A. Werden naturwissenschaftliche Inhalte für die Schüler:innen dieser Klasse im Rahmen eines eigenen Unterrichtsfachs (und nicht als Teil des integrierten Sachunterrichts) unterrichtet?</target>
  <note>AL_TQ - S01A_de-DE</note>
</trans-unit>

That unit looks like this in OmegaT:

id 8007 / segment 1097

Lack of segmentation is a problem for translators and revisers, it makes their task more difficult as the sentence is the unit of text they consider at a time (while keeping an eye on the context of course). Putting several sentences in the same translation unit goes against that principle. The longer the translation unit is and the more sentences it contains, the higher the cognitive effort the linguist needs to make and therefore the higher the changes of overlooking important details.

Lack of segmentation might also reduce the chances for internal repetition, which means some sentences might need to be translated or revised more than once without knowing it, which leads to double work and inconsistencies.

To the multiple-sentence problem it is added that in some cases sentences are broadly dispersed with many empty lines in between. The example above might not seem too bad, but there are other cases where the problem is much worse. Take a deep breath and start scrolling down now:

<trans-unit id="7236" xml:space="preserve" approved="yes">
    <source> <!-- 163 lines! -->

Professional Development to Teach Mathematics
M10.




A. In the past two years, have you participated in professional development in any of the following?

B. Have there been any offers for further training with the following contents in the last two years?

C. Do you need future professional development in any of the following?



 Please check  three  boxes in each line.



yes
no

yes
no

yes
no







a) Mathematics content









b) Mathematics pedagogy/instruction









c) Mathematics curriculum









d) Integrating technology into mathematics instruction









e) Improving students’ critical thinking or problem solving skills









f) Mathematics assessment









g) Addressing individual students’ needs









h) Language awareness in teaching mathematics








    </source>
    <target>

Fortbildung zum Mathematikunterricht
M10.




A. Haben Sie in den letzten zwei Jahren an einer Fortbildungsveranstaltung mit folgenden Inhalten teilgenommen?

B. Gab es in den letzten zwei Jahren Angebote für Fortbildungen mit folgenden Inhalten?

C. Haben Sie in Zukunft Bedarf an Fortbildung in folgenden Bereichen?



 Bitte in jeder Zeile  drei  Kästchen anklicken.



ja
nein

ja
nein

ja
nein







a) mathematische Inhalte









b) Mathematikdidaktik









c) Lehrplan Mathematik









d) Integration von Technologie in den Mathematikunterricht









e) Stärkung der Fähigkeit der Schüler:innen, kritisch zu denken bzw. Probleme zu lösen









f) Leistungsfeststellung in Mathematik









g) Eingehen auf die individuellen Bedürfnisse der Schüler:innen









h) Sprachsensibler Fachunterricht








    </target>
    <note>AL_TQ - M10_de-DE</note>
</trans-unit>

The example above is just not workable for the linguist (neither for translators nor for revisers). It's no longer just a matter of cognitive overload, it's visually impracticable (the text does not fit in the screen). That forces the linguist to do a lot of scrolling or reduce the font size a lot, but in either case the conditions are not good to carry over their task satisfactorily.

Proposed solutions

I assume you're using some home-made routines (e.g. a XSLT stylesheet to carry out the transformation). Segmentation can be a nut hard to crack if done that way from scratch. If that's the case, I would strongly advise to use existing libraries or tools that do that work for you. The XLIFF best practices guide that I sent has links to a few applications, both open-source and commercial, that you could use for this. You could either integrate those libraries in your workflow or post-process the outcome of your workflow with them.

I have used Okapi to produce a new version of your XLIFF file (see file 03_Outgoing/Data_XLIFF_Export_v1_2_20220331142431053.ok.xlf in the folder I am sharing below). I have segmented both the source and the target texts, for which I had to tweak the segmentation rules for the target language a bit, to account of the punctuation specificities of German. I hope I didn't overlook any such case, but it's possible. However the outcome of this will only be reliable as long as both the source text and the target text in each translation units have the same number of line breaks, since line breaks are taken as segmentation points (which leads to the next problem).

Line breaks in the middle of sentences

Your text contains some line breaks in the middle of sentences. For example:

1
2
3
4
5
6
7
<trans-unit id="9544" xml:space="preserve" approved="yes">
    <source>S14. Wie häufig machen Sie die folgenden Dinge, um Schüler:innen nach ihren 
individuellen Lernvoraussetzungen im Sachunterricht zu fördern?</source>
    <target>S14. Wie häufig machen Sie die folgenden Dinge, um Schüler:innen nach ihren
individuellen Lernvoraussetzungen im Sachunterricht zu fördern?</target>
    <note>EXL_TQ - S14_de-DE</note>
</trans-unit>

Line breaks are not a problem per se, but they are a problem if your file is to be processed further to obtain something workable (see the proposed solution to problem #2 above). Added to this problem is the fact that line breaks are not consistent in the source and the target, which is a source of further segmentation errors (segment ¶1097):

1
2
3
4
5
6
7
<trans-unit id="9440" xml:space="preserve" approved="yes">
    <source>a) Ich rege meine Schüler:innen an, eigene <!-- line break HERE -->
Forschungsfragen aus Beobachtungen und <!-- line break HERE -->
Theorien zu entwickeln.</source>
    <target>a) Ich rege meine Schüler:innen an, eigene Forschungsfragen aus Beobachtungen und Theorien zu entwickeln.</target>
    <note>EXL_TQ - S13_de-DE</note>
</trans-unit>

This is what that looks like in OmegaT:
segment ¶1097

Proposed solutions

Rather than creating segmentation exceptions for all those cases, which can become challenging very quickly, I would simply advise to run a sanity check and fix those line breaks that should not be there in the first place, neither in the source text nor in the target text (especially in the source text). I have done that in your file so as to be able to process it further reliably.

I would advise to run sanity checks not only to detect and remove line breaks in the middle of sentences, but also to prevent them in the first place. It should be feasible to add some input validation in your authoring/editing tool, so that users re not allowed to enter submit text that does not comply with certain requirements (e.g. only line breaks allowed at the end of sentences).

Sample files

Here you will find the following files:

.
├── 01_Incoming
│   ├── Data_XLIFF_Export_v1_2_20220331142431053.xlf
│   └── Data_XLIFF_Export_v1_2_20220331142431053.zip
├── 02_Work
│   ├── Data_XLIFF_Export_deu-DEU_forVF_20220401_VF08rpt.xlsx
│   ├── talis2022_xliff_rainbow_proj.tar.gz
│   ├── TALIS24_test1_orig_2022.03.31_OMT.omt
│   └── TALIS24_test2_post_2022.04.04_OMT.omt
└── 03_Outgoing
    └── Data_XLIFF_Export_v1_2_20220331142431053.ok.xlf

In detail:

Edit Report
Pub: 01 Apr 2022 09:23 UTC
Edit: 07 Apr 2022 13:47 UTC
Views: 196