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"
).
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:
That unit looks like this in OmegaT:
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 | <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:
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):
This is what that looks like in OmegaT:
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:
In detail:
- 02_Work/Data_XLIFF_Export_deu-DEU_forVF_20220401_VF08rpt.xlsx: QA report that flags translation inconsistencies in the XLIFF file.
- 02_Work/TALIS24_test1_orig_2022.03.31_OMT.omt: an OmegaT project that shows what the XLIFF file audited looks like in OmegaT
- 03_Outgoing/Data_XLIFF_Export_v1_2_20220331142431053.ok.xlf: an optimal version of the XLIFF file
- 02_Work/TALIS24_test2_post_2022.04.04_OMT.omt: an OmegaT project that shows what the optimal preparation looks like in OmegaT