Weitere konkrete Hinweise zur Bearbeitung von Tags

Die Übersetzer hatten ein paar generelle Fragen zu vergangenen Vectron-Projekten gesammelt, insbesondere zur Anpassung der Tags wegen der Flexion im Tschechischen und auch in anderen Sprachen. Die Antworten sind BLAU.

1. In den Tags werden die Sonderzeichen durch andere Zeichen ersetzt, z. B.:
   Brzd. ovládač sieht wie folgt aus: Brzd.ovládač

Die Frage ist, ob wir bei der Anpassung jetzt die richtigen Sonderzeichen einsetzen sollen oder ob man die Ersatzzeichen behalten muss.
Wenn man diese erhalten muss, hättet ihr vielleicht eine Liste für die Sonderzeichen in den einzelnen Sprachen und die entsprechenden Ersatzzeichen?
Denn das Problem ist, dass bei der Flexion ein neues Sonderzeichen dazukommen kann, welches in der Grundform nicht enthalten ist; dann wüssten wir nicht, was wir einsetzen sollen.

[HS] Das sind XML-Entities die die entsprechenden Unicode-Zeichen darstellen. Sie schreiben einfach die tschechischen Buchstaben als Unicode-Zeichen, und memoQ setzt sie dann in die Entities um.

2. Bei der Vorgehensweise zur Anpassung der Tags gibt es zwei Möglichkeiten:

1. Wir haben eine Einleitung bekommen, in der es heißt, Cursor vor den Tag setzen, Strg+F9 drücken, „inflectedForm“ anpassen, speichern und OK drücken; wenn man das so macht, zeigt sich die angepasste Form in dem Fenster, wo man die Anpassung vornimmt, nicht aber in dem Segment und dem Tag selbst.
2. Man markiert den Tag/stellt den Cursor dahinter, drückt Strg+F9 und bekommt ein ähnliches Fenster, doch hier gibt es die Zeile „val“; wenn man diese dann anpasst, speichert und mit OK bestätigt, sieht man die Änderung auch in dem Segment/Tag.

Die Frage ist, ob es einen Unterschied macht, wie man hier vorgeht. Wir bevorzugen die zweite Form, weil man es dann direkt in dem Segment sieht, sind uns aber nicht sicher, ob es so auch für den Kunden in Ordnung ist.

[HS] Variante b) funktioniert nur im Übersetzungseditor, aber bringt die Änderung nicht nach Cosima. Bitte Variante a) machen, denn der Inhalt des Attributs y.custom.translation ist das, was zählt. Dieser Wert wird nach Cosima importiert; der Text im Segment zwischen öffnendem und schließendem Tag kommt nicht nach Cosima.

3. Die zu flektierenden Tags sind meistens bereits in der entsprechenden Sprache.

Statt z. B. e-Bremse steht bereits in DE e-brzda; dann ist klar, dass man die richtige SK-Form einsetzen muss. Es kommt aber auch manchmal vor, dass in einem Tag ein normalerweise zu flektierendes Wort steht, das hier aber auf DE ist – hat es einen Grund? Beispiel: in SK kommt ep-Bremse im Tag vor – dies soll aber normal übersetzt werden, oder?

[HS] In den Tag kommt rein, was der Redakteur in Cosima als a-ref auszeichnet. Wenn da ein Text als Abkürzung definiert wird, der eigentlich kein Akronym ist, dann hat der Redakteur was falsch gemacht. Wir in der Übersetzung können das aber nicht korrigieren, sondern müssen damit umgehen als wenn’s ein korrekter a-ref wäre.

4. Gibt es vielleicht eine Möglichkeit, dass solche Wörter nicht in Tags auftreten? Denn die Bearbeitung ist leider etwas umständlich und zeitlich sehr aufwendig im Vergleich zu einer normalen Übersetzung. Wenn es z. B. Abkürzungen sind, ist das noch einfach und machbar, aber bei ganzen Wörtern erweist sich das in unseren Vectron-Sprachen etwas problematisch. Wäre klasse, wenn es dafür vielleicht eine einfache Lösung gäbe.

[HS] Ja schon, aber das steuert der Redakteur; wir haben darauf leider keinen Einfluss.

Um auf Nummer sicher zu gehen, noch eine letzte Nachfrage dazu:

Zu 3 haben wir noch eine Nachfrage, um jetzt Missverständnisse zu vermeiden. Kannst Du uns damit bitte helfen?

Ursprüngliche Frage und Antwort:

3. Die zu flektierenden Tags sind meistens bereits in der entsprechenden Sprache.

Statt z. B. e-Bremse steht bereits in DE e-brzda; dann ist klar, dass man die richtige SK-Form einsetzen muss. Es kommt aber auch manchmal vor, dass in einem Tag ein normalerweise zu flektierendes Wort steht, das hier aber auf DE ist – hat es einen Grund? Beispiel: in SK kommt ep-Bremse im Tag vor – dies soll aber normal übersetzt werden, oder?

[HS] In den Tag kommt rein, was der Redakteur in Cosima als a-ref auszeichnet. Wenn da ein Text als Abkürzung definiert wird, der eigentlich kein Akronym ist, dann hat der Redakteur was falsch gemacht. Wir in der Übersetzung können das aber nicht korrigieren, sondern müssen damit umgehen als wenn’s ein korrekter a-ref wäre.

Dürfen wir das also in diesem Beispiel so verstehen, dass wir mit dem Tag „ep-Bremse“ so umgehen, als würde dort korrekt „ep-brzda“ stehen, und folglich in dem Fenster (STRG+F9) bei y.custom.translation die flektierte slowakische Form von „ep-brzda“ einsetzen, den Tag „ep-Bremse“ selbst aber unberührt so stehen lassen sollen? Ist das so korrekt? Könnt ihr uns das bitte noch kurz bestätigen? Vielen Dank!

[HS] Ist korrekt.

Wir sollen das also in diesem Beispiel so verstehen, dass wir mit dem Tag „ep-Bremse“ so umgehen sollen, als würde dort korrekt „ep-brzda“ stehen, und folglich in dem Fenster (STRG+F9) bei y.custom.translation die flektierte slowakische Form (InflectedForm) von „ep-brzda“ einsetzen, den Tag „ep-Bremse“ selbst aber unberührt so stehen lassen.

Hintergrund: Den Tag selbst kann nachträglich nur der Redakteur ändern, weil in COSIMA der Tag „ep-Bremse“, so wie es im Tag steht, mit der a-ref-Tag-ID verknüpft ist. Das muss dann nachträglich bei Siemens geändert werden, das ist aber nicht unsere Aufgabe.

Wenn ihr also Tags habt, die fälschlicherweise noch auf Deutsch sind, sollt ihr bei InflectedForm die flektierte Übersetzung (SK, CS etc.) einsetzen (nach der Anweisung) und sonst nichts ändern!

Ihr könnt euch diese Hinweise auch noch mal hier herunterladen: Weitere konkrete Hinweise zur Bearbeitung von Tags