< zurück

weiter >

Elektronische Texte

Seminar „Maschinelle Übersetzung“

von Manuel Strehl

Abgelegt unter

Schlüsselwörter: , ,

“The North Korean encoding was inspired by the South Korean one but presents certain incompatibilities. In addition, positions 0x0448 to 0x044D fulfill an important state purpose: they contain the names of honorable party president Kim Il-sung and his son and successor Kim Jong-il … a funny way to achieve immortality.”

Quelle: 1

Einleitung

Seit dem 4. vorchristlichen Jahrtausend sind uns schriftliche Zeugnisse überliefert. Immer wieder mussten Menschen in diesem Zeitraum das Kunststück der Abstraktion vollbringen, Sprache durch Objekte ihrer Umgebung darzustellen. Eine zusätzliche Schwierigkeit stellten dabei Einschränkungen der Ausdrucksmöglichkeit dar, wie zum Beispiel eine vorgegebene Reichweite. So wird von Aeneas berichtet, dass er Nachrichten über weite Distanzen mittels eines Systems aus 2 mal 5 Fackeln übermitteln ließ 1, Seite 28. Die Übersetzung griechischer Buchstaben in das „Fackelsystem“ nennt man hierbei Kodierung.

Mit dem 19. Jahrhundert und der Entwicklung der Telegrafie war es schließlich in großem Maße notwendig geworden, Texte in einem Binärformat zu übermitteln. Es entwickelte sich ein Wildwuchs an Kodierungen, dessen Folgen bis heute nachklingen. Insbesondere die Möglichkeit, Nachrichten über Landes- und damit über Sprachgrenzen hinweg zu übermitteln, lieferte Potential für beliebige Fehldeutungen der jeweils auf eine Sprache zugeschnittenen Kodierungen.

Mit der Entwicklung der Computer und der elektronischen Speicherung von Texten kam neben der Zeichenkodierung zusätzlich das Problem unterschiedlicher Dateiformate auf. Dabei wurden jeweils unterschiedliche Methoden benutzt, um Auszeichnungen und Metainformationen zum eigentlichen Text zu speichern.

In dieser Situation sieht sich die maschinelle Übersetzung (MÜ) mit zwei Problemen konfrontiert, die über ihren eigentlichen Zweck, das Übersetzen des Textes, hinausgehen. Zum einen muss eine MÜ-Software in der Lage sein, ein bestimmtes Dateiformat lesen und daraus den Text extrahieren zu können. Dazu gehört neben der Kenntnis des Formats auch das Wissen über die Zeichenkodierung des Textes. Zum anderen muss die übersetzte Information wieder mit den ursprünglichen Auszeichnungen wie Fettdruck oder Fußnoten versehen und in einem für den Nutzer verwendbaren Format, bevorzugt dem Ausgangsformat, gespeichert werden. Dabei kann es z. B. unumgänglich sein, die Zeichenkodierung zu ändern oder dem Dokument neue Seiten hinzuzufügen.

Im Abschnitt 2 gehe ich näher auf Zeichenkodierungen ein. Insbesondere Unicode als Rahmenwerk für Kodierungen, das sich mittlerweile als de-facto Standard etabliert hat, wird betrachtet.

Der Abschnitt 3 beschäftigt sich mit unterschiedlichen Dateiformaten, darunter HTML, Word DOC und PDF, und welche Auswirkung ein bestimmtes Format auf den Übersetzungsprozess haben kann.

Jeder der beiden Abschnitte enthält eine Besprechung von Problemen, die sich jeweils speziell im Hinblick auf MÜ ergeben. Abschließend werde ich die Ergebnisse der vorhergehenden Kapitel kurz zusammenfassen.

Zeichenkodierungen

Mit der Speicherung von Buchstabenfolgen als Bits, also als Serie von 0 und 1, mussten Systematiken entwickelt werden, wie diese Binärreihenfolgen zu interpretieren sind. Dabei wurde auf Vorarbeit der Telegrafen aufgebaut, was jedoch nicht verhinderte, dass sich diverse Nischenlösungen bildeten. 1963 wurde eine Kodierreihenfolge, die aus 7-bit-Blöcken bestand, als ASCII (American Standard Code for Information Interchange) standardisiert und in der Folge in ISO 646 international normiert.

Dem Stand der damaligen Technik geschuldet finden sich im ASCII-Zeichensatz, der 128 Zeichen umfasst, auch Steuer- und Formatierungszeichen, z. B. DEL, ESC und Tabulatoren. Sie stammen aus dem Erbe der Telegrafie und insbesondere die Steuerzeichen wurden nach und nach zwecklos, da z. B. Transferprotokolle mit zunehmendem Reifegrad flexiblere Informationsauszeichnung benötigten.

Die in den 60er und 70er Jahren am weitesten verbreitete Lösung parallel zu ASCII war EBCDIC. Sie stammte von IBM und wurde von der Struktur damals verwendeter Lochkarten geprägt 1, Seite 31. Ihr großer Nachteil gegenüber ASCII war, dass im Alphabet angrenzende Buchstaben in der Kodiertabelle nicht nebeneinander lagen.

Da ASCII nur 7 Bits zur Kodierung verwendete, die bevorzugte Bytegröße aber 8 Bits darstellte, wurden im Laufe der Zeit die oberen 127 Plätze je nach Bedarf mit zusätzlichen Zeichen aufgefüllt. Somit war, nach der vorangegangenen Standardisierung der unteren 127 Plätze, wiederum nichts gewonnen. Die beiden bekanntesten Vertreter unter den erweiterten ASCII-Zeichensätzen sind die Windows Codepages sowie ISO 8859, eine Serie von Standards, die durch verschiedene Belegung der oberen Zeichen unterschiedliche sprachliche Regionen abzudecken versuchen.

In Asien wurde in den 70er Jahren an Alternativen zu ASCII gearbeitet. Da insbesondere in Japan, China und Taiwan die Anzahl darzustellender Zeichen das lateinische Alphabet um ein Vielfaches überstieg, wurde auch schon früh mit Multibyte-Kodierungen experimentiert. Das führende Japan Industrial Standards Committee veröffenlichte 1976 mit JIS C 6220 eine 1-Byte-Kodierung, die auf ASCII basierte, und 1978 mit JIS C 6226-1978 eine 6.694 Zeichen umfassende Multibyte-Kodierung für japanische Texte 1, Seite 42.

In den 80ern legten China und Taiwan und den 90er Korea je eigene Zeichenkodierungen vor. Gleichzeitig mischten Microsoft und Apple mit Betriebssystem-spezifischen Kodierungen im aufstrebenden asiatischen Markt mit.

Alles in allem waren bis zum Jahr 2004 250 bekannte und registrierte Kodierungen zu verzeichnen 1, Seite 49. Diese alle in Anwendungen zu berücksichtigen ist, im besten Falle, hochgradig unwirtschaftlich. Der Bedarf an einem einheitlichen Standard für alle möglichen Symbole war denn auch bereits Anfang der 90er nicht mehr zu leugnen.

Unicode

In dieser Situation, ab 1984, wurde von Adobe und Xerox an einem Standard namens Unicode 2 gearbeitet. Er wurde 1993 veröffentlicht und als ISO 10646 (man beachte: ASCII ist ISO 646) international und insbesondere firmenübergreifend standardisiert. Um die ursprünglichen Firmen entwickelte sich ein Industriekonsortium, das Unicode bis heute aktiv weiterentwickelt 3.

Das Ziel von Unicode ist eine universelle Multi-Byte-Kodierung aller verwendeter und ehemals verwendeter Zeichen. Dabei sind unterschiedliche Hürden zu nehmen, die einem Projekt dieser Ambition im Wege stehen:

  • Zeichen sind nicht identisch mit den Glyphen, die verwendet werden, um erstere darzustellen. Die Schwierigkeit liegt darin, die vorhandenen Glyphen so zu interpretieren, dass man nicht ein Zeichen mehrfach oder gar nicht in den Standard aufnimmt. Diese Unterscheidung, davon abgesehen, dass sie in manchen Fällen nicht eindeutig durchzuführen ist, muss durch den tatsächlichen Gebrauch belegt werden können. Dieses Problem ist für die meiste Kritik an Unicode verantwortlich. So sind z. B. ostasiatische Schriftzeichen unterschiedlicher Sprachen im Standard zusammengelegt, obwohl Muttersprachler der betroffenen Sprachen heftig widersprechen, dass die jeweiligen Zeichen identisch sind.
  • Die Länge einer Zeichenkette ist nicht mehr identisch mit der Länge gespeicherter Bytes. War das auch schon für andere Multibyte-Kodierungen richtig, führt Unicode auch Kodierungen mit variabler Bytelänge ein, in denen die Bitgröße eines Strings nicht mehr allein von der Anzahl Zeichen abhängt, sondern direkt vom Inhalt der Zeichenkette mitbestimmt wird.
  • Die Möglichkeit, Bytes in einer Multibyte-Kodierung unterschiedlich zu sortieren („Little Endian“ und „Big Endian“) sorgt für Unterscheidungsprobleme. Im Zuge der Suche nach einer Lösung wurde von Microsoft das Byteorder Mark (BOM) eingeführt. Dieses Symbol mit der Unicode-Position U+FFFE bzw. U+FEFF soll die Unterscheidung dadurch erlauben, dass das Erscheinen eines der beiden Zeichen am Beginn einer Datei die jeweilige Speicherart markiert. Sein Nutzen ist jedoch in der populären Unicode-Kodierung UTF-8 nicht gegeben und der Einsatz eines BOMs führt regelmäßig zu Kompatibilitätsproblemen.
  • Unicode selbst definiert keine spezielle Zeichenkodierung, sondern nur eine Abbildung von Zeichen auf sogenannte Codepunkte. Um diese Codepunkte als Bits zu speichern, wurden unterschiedliche neue Zeichenkodierungen entwickelt, wobei die beiden berühmtesten und häufigsten UTF-8 und UTF-16 sind. Der neue Standard hat also effektiv an Stelle der alten Vielfalt an Kodierungen eine neue gesetzt. Da diese alle jedoch auf einem einheitlichen Grundregelwerk fußen, ist eine Umwandlung zwischen einzelnen Kodierungen oft deutlich einfacher als zwischen Nicht-Unicode-Kodierungen.

Bei der Aufstellung der Abbildung von Zeichen auf Codepunkte orientiert sich das Unicode-Konsortium an zehn Prinzipien. Diese sollen die universelle Einsetzbarkeit des Standards auch für die Zukunft gewährleisten 4.

  1. Universalität: Es sollen universell alle jemals verwendeten Schreibsysteme berücksichtigt werden.
  2. Effizienz: Die Dokumentation des Standards muss effizient und umfassend geschehen.
  3. Unterschied zwischen Zeichen und Glyphen: Glyphen sind Instanzen von Zeichen, und können in ihrer Form stark voneinander abweichen. Der Standard nimmt nur Zeichen auf.
  4. Wohldefinierte Semantik von Zeichen: Aufgenommene Zeichen müssen klar definiert und von anderen Zeichen abgegrenzt sein.
  5. Reiner Text: Zeichen aus dem Unicode-Standard repräsentieren reinen Text und agieren per se keinesfalls als Auszeichnung oder Metacharakter.
  6. Logische Reihenfolge: Die Zeichen in bidirektionalem Text werden anhand ihrer logischen Reihenfolge gespeichert, nicht anhand der physikalischen oder einer anderen Repräsentationsform.
  7. Vereinheitlichung: Identische Zeichen unterschiedlicher Sprachen und Kulturen werden vereinheitlicht. Dieser Punkt führt insbesondere in Fernost häufig zu Kritik an Unicode.
  8. Dynamische Komposition: Neue Zeichen können aus mehreren Zeichen zusammengesetzt werden. Ein „Ä“ kann aus einem großen „A“ und dem Unicode-Zeichen für Umlaut zusammengesetzt werden.
  9. Equivalente Sätze: Es macht für die Bedeutung einer Zeichenkette keinen Unterschied, ob ein einzelnes Zeichen oder sein dynamisch komponiertes Äquivalent verwendet werden.
  10. Konvertierbarkeit: Alle bestehenden Zeichenkodierungen müssen in Unicode umwandelbar sein.

Daneben sei noch erwähnt, dass das Unicode-Konsortium als eine Art inoffizielle Richtlinie die Stabilität des Standards verteidigt. Das geht mithin soweit, dass sogar Rechtschreibfehler vorangegangener Versionen nicht korrigiert werden 1, Seite 61.

Unicode-Ebenen
Abbildung 1: Darstellung der Unicode-Ebenen. Aus 5, © W3C.

Der interne Aufbau von Unicode wird durch sogenannte Ebenen symbolisiert. Der Standard besteht aus 17 Ebenen, auf die sich die 1.114.111 erlaubten Zeichen aufteilen. Lediglich die Ebenen 1 und 2 sind derzeit mit relevanten Zeichen gefüllt.

Die Ebenen sind in einzelne Blöcke unterteilt, die wiederum möglichst alle Zeichen einer gewissen Gruppe enthalten, z. B. Latin Extended-B, Diacritical Marks, Cyrillic, General Punctuation, …

Probleme der MÜ mit Zeichenkodierungen

Bevor ein elektronischer Text maschinell übersetzbar wird, muss er aus seiner Bit-Repräsentation der MÜ-Software zuerst zugänglich gemacht werden. Das bedeutet, sie muss die hereinkommenden Bits interpretieren können, wozu sie die verwendete Zeichenkodierung kennen muss.

Auf der anderen Seite kann der Fall auftreten, dass die übersetzte Zeichenkette Zeichen enthält, die nicht in der Zeichenkodierung des Ausgangsdokuments dargestellt werden können. In diesem Fall muss die MÜ-Software in der Lage sein, eigenständig eine neue Kodierung zu wählen und das übersetzte Dokument in dieser zu speichern.

Erschwert wird diese Arbeit unter anderem durch folgende Punkte, die berücksichtigt werden müssen.

  • Der ISO 2022-Standard erlaubt, mehrere Zeichenkodierungen in einem Dokument zu verwenden. Ist dies der Fall, muss auf Escape-Zeichen zum Kodierungswechsel geachtet werden.
  • Durch die Änderung der Zeichenkodierung kann sich eine zuvor eindeutige Abbildung der Zeichenketten- auf die Bytelänge als ungültig erweisen. Dies muss insbesondere bei dem Aufbau des Zieldokuments beachtet werden.
  • Effizienz-Überlegungen beinhalten z. B. die Entscheidung, ob nach einer Übersetzung UTF-8 oder UTF-16 verwendet werden soll. Für europäische Sprachen ist erstere effizienter, während sie für asiatische Sprachen zu einer deutlichen Vergrößerung des Dokuments führt.
  • Schreibrichtung und Kontrollzeichen sind unter Umständen durch die Zeichenkodierung vorgegeben oder ändern sich im Verlauf der Übersetzung.

Dateiformate

Wie eingangs erwähnt ist die Möglichkeit, zu Texten Zusatzinformationen zu speichern, ein essenzielles Bedürfnis der elektronischen Datenverarbeitung. Diese Zusatzinformationen bestimmen Formatierung und Zugänglichkeit des Textes, etwa durch die Auszeichnung von Überschriften oder fett gesetztem Text.

Es gibt unterschiedliche Methoden, wie die Informationen zum eigentlichen Text hinzugefügt werden. Diese Methoden können offengelegt sein, wie es z. B. der PDF-Standard (6) ist, oder proprietär, was lange Zeit für Microsofts DOC-Format galt. Außerdem ist eine sinnvolle Unterscheidung die zwischen menschenlesbaren und binären Dateiformaten.

Zu ersteren gehört insbesondere HTML (7). Die Hypertext Markup Language ist ein Vertreter der Familie der Auszeichnungssprachen. Hier werden Metainformationen direkt in den Text geschrieben. So sieht eine Formatieranweisung für Fettdruck folgendermaßen aus:

Dies ist <b>fett gedruckter</b> Text.

Auszeichnungssprachen ändern also den ursprünglichen Text. Neben HTML fallen auch RTF (Rich Text Format8) und LATEX in diese Kategorie. Die Extensible Markup Language (XML, 9) ist mittlerweile die am weitesten verbreitete Metasprache zur Definition von Auszeichnungssprachen.

Alternativ können Stilangaben vom eigentlichen Text separiert gespeichert werden. Dazu wird einerseits der vorhandene Text unverändert gespeichert, andererseits werden Stilangaben in einem eigenen Abschnitt mit gewissen Positionen innerhalb des Textabschnitts verknüpft, z. B. mit dem fünften bis zwölften Byte. Diese Variante wird von den meisten Office-Formaten, insbesondere von Microsoft Word, verwendet.

Office-Dokumente beinhalten neben einfachen Textformatierungen komplexere Strukturen wie Fußnoten oder andere Medien. Im Zuge der Maschinellen Übersetzung muss auf diese zusätzlichen Inhalte und deren Position im Fließtext besondere Rücksicht genommen werden. Im Rahmen des METAL-Projekts 10 beschreibt T. Schneider den tatsächlichen Nutzanteil sowie den Workflow folgendermaßen:

[M]ore than half of the characters on a page may be nontranslatable material […] It would be highly uneconomical to manually extract the text portions to be translated and afterwards manually re-input them. […] A translation run usually goes through the following steps: Once the text has been received in machine-readable form, a set of programs on the SINIX system checks the pages for tables, graphs etc and generates a layout file of the page. The individual translation units, usually sentences, are automatically recognized, numbered consecutively and extracted from the layout file.

Quelle: 11

Zur Verteilung verschiedener Dateiformate im Bereich der MÜ sei hier exemplarisch auf Stadler und Peter-Spörndli 12 verwiesen. Dort werden für CLS Communication, ein MÜ-System im Bereich „finance, insurance and life sciences industries“, die Formate DOC, HTML, einfacher Text und RTF für Lese- und Schreibunterstützung als signifikant wichtig beschrieben. Dabei stellt DOC das wichtigste Format dar. Daneben wird trotz fehlender Unterstützung von den Anwendern regelmäßig versucht, PDFs zu übersetzen. An der Unterstützung von Powerpoint-, Excel- oder anderen XML-Formaten scheint kein großer Bedarf zu bestehen.

Eine besondere Herausforderung stellt die Text-Extraktion aus PDF-Dokumenten 1314 ebenso wie das anschließende erneute Erstellen des Ausgabedokuments dar. Da es sich bei PDF um ein Druckformat handelt, und damit der Zugriff auf den Textinhalt verglichen mit der möglichst detailgetreuen Wiedergabe nachrangig ist, bietet das PDF-Format keinen einheitlichen und zuverlässigen Weg an, den Dokumentinhalt aus der Datei zu gewinnen. Dabei lassen sich mehrere Probleme identifizieren:

  • Es gibt kein Konzept einer Zeichenkette. Zusammengehörende Buchstaben können in der Datei nebeneinander gespeichert sein, müssen dies jedoch nicht.
  • PDF-Dokumente sind stark am Konzept einer Seite ausgerichtet. Text, der zwischen Seiten umbricht, muss bei der Extraktion manuell wieder zusammen gefügt werden.
  • Die Schriftzeichen müssen keiner standardisierten Zeichenkodierung entsprechen. Wird nur ein Teilset einer Schriftart eingebettet, darf die erstellende Software entscheiden, die Glyphen neu anzuordnen und dadurch auch die Bit-Information im Text zu ändern.

Probleme der MÜ mit Dateiformaten

Neben den gerade angesprochenen Problemen mit dem PDF-Format zeigen auch Auszeichnungs- und Office-Formate spezifische Schwierigkeiten bei der automatischen Gewinnung und der erneuten Speicherung der Textinformationen.

Auszeichnungsformate

In der Boom-Phase des WWW erreichten diejenigen Browser einen großen Marktanteil, die auch Seiten darstellten, die dem HTML-Standard nicht zu 100% folgten. Dadurch kommt es zum Effekt der „tag soup“, d. h., als HTML deklarierte Dokumente können in ihrer Struktur deutlich von der Vorgabe der Spezifikation abweichen. Um dennoch universell einsetzbar zu sein, müssen MÜ-Programme mit diesen Dateien umgehen können.

Da Auszeichnungsformate direkt im auszuzeichnenden Text operieren, ist es wichtig, Metazeichen einzuführen, die das Maskieren bedeutsamer Zeichen erlauben. Darüber hinaus bieten viele Formate für die Eingabe von Zeichen jenseits des ASCII-Sets spezielle Notationen an. In HTML gibt es dazu die &…;-Syntax, die aus SGML stammt. LATEX nutzt den Backslash „\“ zum Maskieren und zur Einleitung der Sonderzeichen-Syntax. Die MÜ-Software muss die jeweiligen Eigenheiten der Auszeichnungssprache kennen, um Text richtig zu extrahieren und Maskierungen nicht fälschlich zu übernehmen oder auszulassen.

Officeformate

Bei Formaten, in denen die Formatierung getrennt vom Text vorgenommen wird, ist die größte Herausforderung die korrekte Bestimmung des neuen Ortes und der neuen Länge für die vorhandenen Formatierungsanweisungen. Das kann dadurch erschwert werden, dass der bisherige Träger einer Anweisung in der Übersetzung nicht mehr auftaucht. Kritisch wird dies bei Fußnoten, wenn der Ankerort im übersetzten Text nicht mehr bestimmt werden kann.

Ändert sich die Schreibrichtung des Dokuments, müssen Tabellen sowie Medieninhalte neu ausgerichtet werden. Zusammen mit neu dazugekommenen oder entfallenden Seiten stellt dies ebenfalls ein nicht zu unterschätzendes Problem dar. Kopf- und Fußleisten, deren Text sich in der Übersetzung bedeutend erweitert, müssen ebenfalls im neuen Dokument untergebracht werden.

Dateiformate für Übersetzer

Es sei der Vollständigkeit halber darauf hingewiesen, dass es speziell für den Bedarf professioneller Übersetzer eigene Dateiformate gibt. Diese spielen jedoch in der MÜ keine oder eine verschwindende Rolle.

Im Bereich der Software-Entwicklung, insbesondere der Open Source-Bewegung, hat sich das GNU-Gettext-Format durchgesetzt. Es ist ein einfaches plain text-Format, in dem Original und übersetzte Zeichenkette untereinander stehen. Ein Beispiel für einen Eintrag in einer Gettext- oder PO-Datei sieht so aus:

# Kommentar: Ein Eintrag in einer .po-Datei
msgid "Here’s looking at you kid."
msgstr "Ich seh’ dir in die Augen, Kleines!"

XLIFF, das XML Localization Interchange File Format 15, ist ein XML-Format, das den gleichen Zweck erfüllt und vielfach im Bereich technischer Dokumentation eingesetzt wird. Der Vorteil des XML-basierten Formats ist die Möglichkeit, es innerhalb eines XML-Workflows einsetzen zu können, wie es z. B. Schnabel 16 zeigt. Das folgende Beispiel zeigt einen Abschnitt einer XLIFF-Datei.

<trans-unit id="3" maxbytes="114">
  <source xml:lang="en-US">An application to manipulate and
    process XLIFF documents</source>
  <target xml:lang="de-DE">Eine Anwendung zur Manipulation
    und Verabreitung von XLIFF-Dokumenten</target>
</trans-unit>

Zusammenfassung

Das maschinelle Übersetzen von Texten beginnt bereits bei der Extraktion des Textes aus dem Quelldokument. Um die relevanten Daten zu erhalten, muss die MÜ-Software über Details des zu übersetzenden Dokuments Bescheid wissen. Zum einen bestimmt die Zeichenkodierung, wie der Text ursprünglich in Bits übersetzt wurde. Zum anderen ist das Dateiformat für die Spezifizierung von Zusatzinformationen zuständig.

Es gibt eine unüberschaubare Anzahl an Kombinationen aus Kodierung und Format. Die gute Nachricht ist jedoch, dass sich bei den Zeichenkodierungen Unicode-basierte derzeit durchsetzen. Bei den Dateiformaten gibt es, je nach Einsatzgebiet der MÜ-Software, ebenfalls nur einige wenige relevante Formate. Insbesondere XML-basierte Sprachen bilden dort mittlerweile die größte Gruppe, einschließlich neuerer Office-Formate wie ODT und OpenXML.

Dennoch muss die MÜ-Software in vielen Fällen Entscheidungen hinsichtlich des Zieldokuments treffen. Wenn Zeichenketten nicht als solche erkennbar sind, wie es z. B. in PDF-Dokumenten vorkommen kann, muss aufgrund der Position der einzelnen Glyphen der Zusammenhang erkannt werden. Wird keine Zeichenkodierung mit dem Dokument geliefert, muss aufgrund der vorkommenden Bitmuster geraten werden. Die Zeichenkodierung muss selbstständig angepasst werden, wenn Zeichen des Zieltextes nicht in der Ursprungskodierung vorhanden sind.

Darüber hinaus kann es im Layout des Zieldokuments zu beträchtlichen Veränderungen kommen. Neu hinzu gekommene Seiten, verschwindende Fußnotenanker oder überlange Kopfleisten müssen jeweils beachtet und mit einer angebrachten Reaktion des Programms behandelt werden.

Die vorangegangenen Abschnitte haben gezeigt, dass die Arbeit eines MÜ-Vollprogramms nicht erst beim Übersetzen beginnt, oder gleich danach wieder aufhört. Vielmehr muss eine Software, die Dokumente vollständig übersetzen und damit anderssprachigen Lesern zugänglich machen soll, in vielerlei Hinsicht zusätzliche Funktionen besitzen, die sie auf Eventualitäten des Alltagseinsatzes vorbereiten.

Literatur

  1. Y. Haralambous, Fonts & Encodings. O’Reilly, 2007.
  2. “Unicode Consortium.” Webseite. http://www.unicode.org, besucht am 17. 07. 2009.
  3. J. Bettels and F. A. Bishop, Unicode: A Universal Character Code, Digital Technical Journal 5, (1993), no. 3,.
  4. The Unicode Consortium, The Unicode Standard, Version 4.0.0, ch. 2. Addison-Wesley, Boston, 2003.
  5. “Tutorial: Character sets & encodings in XHTML, HTML and CSS.” Webseite. http://www.w3.org/International/tutorials/tutorial-char-enc/, besucht am 07. 08. 2009.
  6. “Adobe PDF-Spezifikation.” Webseite. http://www.adobe.com/devnet/pdf/pdf_reference.html, besucht am 17. 07. 2009.
  7. “XHTML 1-Spezifikation.” Webseite. http://www.w3.org/TR/xhtml1, besucht am 17. 07. 2009.
  8. “Rich Text Format (RTF) Specification, version 1.6.” Webseite. http://msdn.microsoft.com/en-us/library/aa140277.aspx, besucht am 17. 07. 2009.
  9. “XML 1.0-Spezifikation.” Webseite. http://www.w3.org/TR/xml/, besucht am 17. 07. 2009.
  10. W. S. Bennett and J. Slocum, The LRC machine translation system, Comput. Linguist. 11, 111–121 (1985), no. 2–3,.
  11. T. Schneider, The METAL System. Status 1991, in Progress in Machine Translation, S. Nirenburg, ed., pp. 99–103. IOS Press, 1991.
  12. H.-U. Stadler and U. Peter-Spörndli, The Quest for Machine Translation Quality at CLS Communication, in Proceedings of MT Summit XI, pp. 435–442. 2007.
  13. W. Lovegrove and D. Brailsford, Document Analysis of PDF Files: Methods, Results and Implications Electronic Publishing 8, 207–220, no. 2–3, 1995.
  14. T. Hassan and R. Baumgartner, Intelligent Text Extraction from PDF Documents, in CIMCA ’05: Proceedings of the International Conference on Computational Intelligence for Modelling, Control and Automation and International Conference on Intelligent Agents, Web Technologies and Internet Commerce Vol-2 (CIMCA-IAWTIC’06), pp. 2–6. IEEE Computer Society, Washington, DC, USA, 2005.
  15. “XLIFF Version 1.2 Specification.” Webseite. http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html, besucht am 13. 08. 2009.
  16. B. Schnabel, Translating SVG with XLIFF and Open Standards, in SVG Open, 2008. http://www.svgopen.org/2008/papers/53-Translating_SVG_with_XLIFF_and_Open_Standards/, besucht am 07. 08. 2009.