In der MIF-Datei werden beide Zeichen unterschieden, d.h. sie überleben Übersetzungsprozesse.

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).