Lokalisierung von OmegaT ins Arabische – "diff -u"

Lokalisierung von OmegaT ins Arabische –
"diff -u"
Es sind bereits sieben Jahre vergangen, seitdem ich an der Lokalisierung von OmegaT
ins Arabische mitgewirkt habe. Der Grund dafür ist heute
1
wie damals
2
derselbe:
OmegaT ist freie Software, und freie Software macht Spaß. ;-) Für diejenigen, die es
nicht kennen, OmegaT ist ein CAT-Tool mit integrierter Rechtschreibprüfung von
Hunspell und einigen Funktionalitäten, die man auch bei den konventionellen
Programmen auf dem Markt findet, darunter:
• eine Autovervollständigungsfunktion
• eine integrierte Tagvalidierung
• das Erzeugen und Importieren von Translation Memories
• die Erstellung von terminologischen Datenbanken
• das Anlegen von Segmentierungsregeln
• die Suche und Festlegung von Segmentierungsregeln anhand von regulären
Ausdrücken
Lokalisierung von OmegaT ins Arabische – 'diff -u'
© Faycal Alami Hassani, http://globaltech-translations.com, 2015 – Folie 1

Lokalisierung von OmegaT ins Arabische –
"diff -u"
Hier ein paar Eindrücke von der ersten Phase
3
der Übersetzung, und ein paar Tipps, wie
man gewisse Probleme bezüglich der Bidirektionalität in Linux lösen kann. Des Weiteren
wurden auch einige Probleme dokumentiert, die mir bei der Übersetzung begegnet sind.
OmegaT mit der arabischen GUI starten
Die Übersetzung der Dokumentation der neuen Version wurde selbstverständlich mit
OmegaT durchgeführt. Um OmegaT mit den arabischen Menüs starten zu können, muss
man folgenden Befehl in dem Ordner, in dem sich die Datei 'OmegaT.jar' befindet,
ausführen:
java -jar -Duser.language=ar OmegaT.jar

Abgleich der unterstützten Formate
Version 1.7.3, 2008 Version 3.5.2, 2015
• Plain Text
• HTML, XHTML
• HTML Help Compiler
• OpenDocument/OpenOffice.org
• Java resource bundles
• INI-Dateien
• PO-Dateien
• DocBook
• Microsoft OpenXML
• Okapi Monolingual XLIFF
• Plain Text
• HTML, XHTML
• HTML Help Compiler
• Document/OpenOffice.org
• Java resource bundles
• INI-Dateien
• PO-Dateien
• DocBook
• Microsoft OpenXML
• Okapi Monolingual XLIFF

Version 1.7.3, 2008 Version 3.5.2, 2015
• DTD-Dateien
• DocuWiki-Dateien
• SubRip-Dateien
• Magento CE Locale CSV
• QuarkXpress Copy FlowGold
• ResX-Dateien
• Android-Ressourcen
• Latex
• Help & Manual-Daeien
• Typo3 LocManager

Version 1.7.3, 2008 Version 3.5.2, 2015
• Wix
• Flash XML export
• Wordfast XML export
Die Liste der untersützten Formate wurde erweitert, wie man der Tabelle entnehmen
kann. Somit entfällt teilweise der Aufwand, die Dateien erst mit externen Tools
vorzubereiten, bevor man mit der Übersetzung loslegt. Auf der Formatebene werden
Dateien in OmegaT in zwei Hauptkategorien unterteilt: Reintext-Dateien
4
und formatierte
Textdateien
5
. Die gewünschte Kodierung zur Bearbeitung der Dateien mit dem
passenden Filter kann man im Filterdialog bestimmen. Dazu muss man zum Menüpunkt
"Projekt > Optionen" gehen, und auf "Dateifilter..." klicken.

Und los geht's...
Da ich für mein damaliges Projekt weder ein TM noch eine terminologische Datenbank
erstellt habe, muss ich dies jetzt im neuen Projekt erledigen. Ein neues Projekt kann man
über die Tastenkombination "Strg+Umschalt+N" oder über das Menü "Projekt > Neu..."
anlegen. Daraufhin erscheint das Fenster "Neues Projekt erstellen", in dem man folgende
Parameter festlegen kann:
• Die Sprachen der Quell- und Zieldateien
• Die Tokenizer
6
und ihr Verarbeitungsverhalten
• Die Einstellungen der Standard- und Projektspezifischen-Dateifilter
• Die Speicherpfade sämtlicher Projektdateien
Sobald man die o.g. Felder ausgefüllt und die benötigten Dateien oder Verzeichnisse in
den Quellordner kopiert hat, werden die übersetzbaren Segmente importiert und im
Editor geladen. Standardmäßig befindet sich eine Kopie des Quelltextes im Zielfeld, wo
die Übersetzung eingetippt wird. Dies kann man jedoch ändern, in dem man das
Optionsfeld "Segment leer lassen" unter "Optionen > Editierverhalten..." aktiviert.
Nachdem das Segment übersetzt wurde, klickt man auf ENTER, um zum nächsten Satz
zu gelangen.

Abschluss der Übersetzung und Erstellung der
Zieldokumente
Die Übersetzung der ersten Dateien ins Arabische lief flott und ohne schwerwiegende
Probleme. Als die Übersetzung gespeichert wurde, ließ sich die readme-Datei mit gedit
jedoch nicht öffnen. Im Terminal erschien folgende Fehlermeldung:
ERROR:../../gi/pygi-argument.c:1583:_pygi_argument_to_object:
code should not be reached
Um diese Fehlermeldung zu beseitigen, musste ich das Plugin Mehrfachbearbeitung in
gedit unter "Einstellungen -> Plugins -> Mehrfachbearbeitung" deaktivieren. Beim
zurückspringen zu einem bereits übersetzten Segment ins Arabische zeigte der Editor
manchmal ein seltsames Verhalten. Wenn ich ein bestimmtes Wort anklicke, um es zu
editieren, springt der Mauszeiger automatisch zu einer anderen Stelle in der gleichen
Zeile, und die eingefügten Zeichen werden an diese Position gesetzt. Bis jetzt konnte ich
nicht feststellen, woran dieses Problem liegt. Sobald ich eine Erklärung dafür habe,
werde ich dies in der aktualisierten Version dieser Präsentation dokumentieren.

Darstellungsprobleme in gedit
Der bidirektionale Unicode-Algorithmus garantiert nicht immer einen optimalen Textfluss,
wenn die Sätze arabische und lateinische Buchstaben gleichzeitig beinhalten.
Beispiel in gedit

Das bidirektionale Steuerzeichen: Dein Freund
und Helfer
Bidirektionale Steuerzeichen helfen dem Unicode-Algorithmus da, wo er die Anordnung
der Zeichen falsch interpretiert. Für die Speicherung der einzelnen Zeichen verwendet
der Unicode-Standard keine visuelle, sondern eine logische Reihenfolge. Laut Definition
des W3C-Gremiums werden bei der logischen Reihenfolge die Buchstaben in der
Reihenfolge im Speicher abgelegt, wie sie normalerweise geschrieben und gesprochen
werden. Bei LTR-Sprachen werden die Zeichen jedoch in die entgegengesetzte Richtung
zu den Zeichen der RTL-Sprachen gezeigt. Um das Problem der Darstellung von
Schriften mit unterschiedlichen Schreibrichtungen zu lösen, wird der BiDi-Algorithmus
von Unicode angewandt. Dieser Algorithmus bestimmt die Schreibrichtung des
eingetragenen Textes anhand der Schreibrichtungsmerkmale jedes eingetippten
Zeichens.

und Helfer
In unserem konkreten Fall werde ich die Steuerzeichen U+202A, U+202C und U+200F
verwenden, um die Textrichtung zu korrigieren. Doch zunächst einmal muss man
erläutern, was diese bidirektionalen Steuerzeichen einzeln für eine Funktion erfüllen.
Unicode-
Nr. Bezeichnung Beschreibung
U+202A LTR-Embedding Den folgenden Text als eingebetteten LTR-Text
behandeln
U+202C POP Directional
Formatting
Die Wirkung des letzten LRE, RLE, RLO oder
LRO-Zeichens beenden
7
U+200F RTL-Mark Rechtsläufiges Nullbreitenzeichen (nicht-arabisch)

und Helfer
Jetzt wo wir die Wirkung der einzelnen BiDi-Steuerzeichen kennen, stellt sich die Frage,
wie wir diese in einem Linux-System einsetzen können. Dazu drücken wir gleichzeitig auf
'Strg+Shift' und den Buchstaben 'u'. Anschließend tippt man die entsprechende
Zeichenkette ein (202a, 202b, 202c, usw.). Bei dem Steuerzeichen U+202A zum Beispiel
werde ich mein BiDi-Zeichen am Anfang des Textblocks platzieren, der als eingebetteter
LTR-Text behandelt werden soll. Da ich nicht will, dass dieser Effekt auf den gesamten
Absatz angewandt wird, muss ich das PDF-Steuerzeichen (POP Directional Formatting)
am Ende meines Textblocks platzieren. Somit erhalte ich folgendes Ergebnis, was der
richtigen Schreibweise im Arabischen entspricht:

und Helfer
Bei den Sätzen, die vollständig aus lateinischen Buchstaben bestehen, wurde der Text
logischerweise links platziert, wie man das am oberen Beispiel in gedit erkennen kann.
Da dies nicht der richtigen Textanordung in meinem Dokument entspricht, werde ich hier
das BiDi-Steuerzeichen U+200F am Anfang des Satzes platzieren, damit er dann rechts
steht. Dazu werde ich wie oben beschrieben vorgehen ('Strg+Shift' + u + 200F).

Hinweise zur Erstellung der Präsentation
Diese Präsentation wurde mit gedit, restructuredText und rst2pdf erstellt. Für die
Syntaxhervorhebung wurde die letzte Version von gedit-reST-plugin verwendet.
1 2015, Version 3.5.2
2 2008, Version 1.7.3
3 Zur Zeit der Entstehung dieser Zeilen habe ich an den Dateien
'readme.utf8' und 'Bundle.properties' gearbeitet.
4 z.B. ASCII-Text, INI-Dateien
5 z.B. DocBook, XLIFF, etc.
6 Mittels Tokenisierung können die Flexionsformen im Quelltext
erkannt und auf die Grundform zurückgeführt werden.
7 Für eine detailliertere Beschreibung sämtlicher o.g. Steuerzeichen,
s. folgenden Link: http://unicode.org/reports/tr9/

Lokalisierung von OmegaT ins Arabische – "diff -u"

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (10)

Lokalisierung von OmegaT ins Arabische – "diff -u"