Als alter Hase war mir (und anderen) eine Besonderheit von FrameMaker schon lange in Fleisch und Blut übergegangen: Sobald ein Wort in Kontakt mit einem Sonderzeichen, insbesondere dem geschützten Leerzeichen (Strg+Lz) kam, wurde es für die automatische Silbentrennung nicht mehr berücksichtigt.
Am Rande bemerkt: Über die Qualität jeglicher Silbentrennungsalgorithmen kann man durchaus verschiedener Meinung sein…
Im Rahmen der Tests der Unicode-fähigen Version 8 war mir aufgefallen, dass sich das geschützte Leerzeichen auf zwei Arten erstellen lässt: Wie bisher mit Strg+Lz und zusätzlich mit dem typischen Windows-Kürzel Alt+0160. Allerdings unterschieden sich die die Darstellungen im Dokument, denn letzteres war nicht als Steuerzeichen zu erkennen, verhielt sich aber dennoch korrekt.
Jetzt wurde, ein klein wenig zufällig, im Forum bei hilfdirselbst.ch entdeckt, dass sich nicht nur das Erscheinungsbild im Dokument sondern auch die Auswirkung auf die Silbentrennung unterscheidet:
Bei der Verwendung von Alt+0160 werden Worte getrennt!
Ich hatte vergessen, dass ich das seinerzeit schon in Testdokumenten bemerkt hatte, siehe Screenshot mit nachträglich hervorgehobenen Alt+0160-Leerzeichen:
Die beiden Versionen des umbruchgeschützten Leerzeichens werden auch im Dialog Suchen/Ändern unterschieden: Das alte suchen Sie mit Backslash Leerzeichen (\ ), das neue geben Sie per Alt+0160 ein. Auf diese Weise können Sie das eine durch das andere ersetzen. In der MIF-Datei werden beide Zeichen unterschieden, d.h. sie überleben Übersetzungsprozesse. Beim Speichern als XML wird aus beiden das korrekte Unicode-Zeichen \u00A0 und beim Öffnen der XML-Datei dann (leider) das alte FrameMaker-Zeichen (analog Strg+Lz). Was sich bei Bedarf modifizieren ließe.
2 Kommentare
Da ist dann doch etwas Vorsicht sinvoll. Zumindest bei Trados bis 2007 Suite (8.3) ist das so, da tatsächlich zwischen den beiden Zeichen unterschieden wird:
Der internal tag repräsentiert dabei den “klassischen” Hard Space (hs) via Strg/Ctrl+Leerzeichen. Bei der Rückkonvertierung werden auch beide wieder richtig zurück in die MIF geschrieben.
In SDL-Trados Studio 2009 sieht das (derzeit noch, Stand Service Pack 1) etwas anders aus. Dort gibt es in den MIF Filter Settings die Option “Sonderzeichen als Text anzeigen”. Ist diese aktiviert, werden die FrameMaker-spezifischen Sonderzeichen nicht mehr als Tags dargestellt, sondern in die entsprechenden Unicode-Zeichen “gemappt”. Das hat zur Folge, dass z.B. der <Char HardSpace> (aus der MIF-Datei) nicht als Tag dargestellt wird, sondern in Unicode \u00A0 (NO-BREAK SPACE) gemappt wird. Nach der Übersetzung werden alle \u00A0 wieder in ein <Char HardSpace> in die MIF-Datei geschrieben, weil das sozusagen der “offizielle” FrameMaker-Hardspace ist. Ergebnis: die “unsichtbaren” Alt+0160 gehen in jedem Fall verloren und werden zu klassischen FrameMaker-Hardspaces.
Ähnlich sieht es bei Across aus: Across bis Version 5 E unterscheidet gar nicht zwischen <Char HardSpace> und Alt+0160. Beides wird in Across bei eingeblendeten Sonderzeichen als “°” dargestellt und in der Übersetzung als <Char HardSpace> rausgeschrieben.
Das noch relativ unbekannte MemoQ [Meine Standnachbarn auf der tekom-Tagung 2009! mmh] unterscheidet bis Version 3.6.9 übrigens wie Trados ebenfalls zwischen <Char HardSpace> und Alt+0160: <Char HardSpace> wird im Editor als Tag dargestellt, und die Alt+0160-Glyphe bleibt eine solche. Leider zeigt der MemoQ-Editor das Alt+0160-Leerzeichen allerdings nicht an (also nicht wie üblich als °, sondern als normales Leerzeichen). Dass ein geschütztes Leerzeichen vom Übersetzer also in die Übersetzung übernommen wird, möchte ich mal als “extrem unwahrscheinlich” bezeichnen, da er es gar nicht sehen kann.
Generell gibt es aber für die Verwendung von \u00A0 (Alt+0160) das Problem, dass dies von allen übliche Editoren ja nur dann angezeigt wird (üblicherweise als “°”), wenn die Sonderzeichen eingeblendet werden. Erfahrungsgemäß tendieren Übersetzer eher dazu, mit ausgeblendeten Sonderzeichen zu arbeiten (“so kann ich mich besser auf den Inhalt konzentrieren”), was mit schöner Regelmäßigkeit dazu führt, dass die umbruchgeschützten Leerzeichen in den Übersetzungen fehlen. (Irgendwie scheint es sowieso unter Übersetzern ein Massenphänomen zu sein, nicht auf umbruchgeschützte Leerzeichen zu achten — wenn es den überhaupt bekannt ist.)
Ähnliche Überraschungen hält im Übrigen auch die Trennempfehlung (SOFT HYPHEN, \u00AD) bereit. Die Eingabe Strg/Ctrl+- (Bindestrich) ergibt das altbekannte FrameMaker-Sonderzeichen für die Trennempfehlung (ähnlich dem hochgestelltem T). In die MIF wird dieses als <Char DiscHyphen> rausgeschrieben.
Nun kann \u00AD auch via Alt+0173 eingegeben werden. Das erzeugt zwar tatsächlich auch in FM ein Zeichen \u00AD, das so auch in die MIF-Datei geschrieben wird. Allerdings wird das Zeichen “-” immer dargestellt (also auch bei ausgeblendeten Sonderzeichen) und trennt gar nicht bzw. wirkt wie ein umbruchgeschützter Bindestrich (\u2011).
Vielen Dank für diese Präzisierungen! Es unterstützt mich darin, Kunden mit vielen Sprachen zum Ausschalten der Silbentrennung zu raten!