Trennstrich: Bug oder Feature?
Johannes Graubner (Transcom)
Hallo Stefan (Gentz) und alle übrigen,
dieser Tage bekam ich eine Übersetzung zurück (MIF-Dateien, in der Datei als Version 11 gekennzeichnet), in der bei Ansicht in FrameMaker 2015 jede Menge Striche mitten in den Wörtern standen – die da nicht hin gehörten. Die genauere Untersuchung ergab: Das waren alles „Automatische Trennstriche“ (so die Bezeichnung im Suchen/Ändern-Pod; in MIF als \x06 kodiert).
Meine Vermutung: Die Übersetzung wurde irgendwo im Prozess mit einer Textverarbeitung bearbeitet, in dem automatische Silbentrennung eingeschaltet war, anschließend sind die Trennzeichen nie ausgefiltert worden sondern wurden durch alle Stufen (Translation Memory) bis in die MIF weitergegeben.
Meine Frage: Ist das als Bug zu sehen, dass FM diese automatischen Trennstriche als generell druckbare Zeichen interpretiert? Sollten diese vielleicht
· Ausgefiltert werden?
· In bedingte Trennstriche gewandelt werden?
(Was den Nachteil hätte, dass das jeweilige Wort nur noch an der Stelle zeilenumbrochen würde.)
· Als Vorzugstrennposition im Falle eines Zeilenumbruchs gewertet werden, ansonsten aber ausgeblendet werden?
PS: Immerhin, über die Option, nach „Autom.Trennstrich“ suchen zu können, konnten die Striche problemlos aus kompletten Büchern gelöscht werden – ohne die FM-interne automatische Trennfunktion zu irritieren.
Viele Grüße
Johannes
Johannes Graubner
Transcom. Ing.-Büro Johannes Graubner
Büro für technische Kommunikation
- Handbücher - Schulungen - Internet -
mailto:grau...@transcom.de Tel. 03641-620540 / 0179-66 55 215
http://www.transcom.de Fax 03641-620541
Burgweg 7, 07749 Jena, Germany
Johannes Graubner (Transcom)
PS:
Formal sicher korrekt aber im Sinne von Fehlererkennung besonders ärgerlich: Die Rechtschreibprüfung ignoriert die automatischen Trennstriche. Wenn das Wort ohne Trennstrich korrekt ist, wird es auch mit Trennstrich nicht als fehlerhaft ausgewiesen.
Dafür, dass die Anzeige ein Bug und kein Feature ist, spricht, dass ich den Trennstrich für sich alleine nicht kopieren und anderswo einfügen kann – allerdings lässt er sich einfügen, wenn er zusammen mit Buchstaben davor _und_ danach kopiert wurde.
--
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "frameusers-de" sind.
Für das Erstellen von Beiträgen in dieser Gruppe senden Sie eine E-Mail an
frameu...@googlegroups.com
Um sich von dieser Gruppe abzumelden, senden Sie eine E-Mail an
frameusers-d...@googlegroups.com
Für Nachrichten an den »Eigentümer« der Gruppe, senden Sie eine E-Mail an
frameuser...@googlegroups.com
Weitere Optionen finden Sie in dieser Gruppe unter
http://groups.google.com/group/frameusers-de?hl=de
---
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "frameusers-de" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an frameusers-d...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.
Michael Müller-Hillebrand
Am 24.11.2016 um 12:23 schrieb Johannes Graubner (Transcom) <grau...@transcom.de>:dieser Tage bekam ich eine Übersetzung zurück (MIF-Dateien, in der Datei als Version 11 gekennzeichnet), in der bei Ansicht in FrameMaker 2015 jede Menge Striche mitten in den Wörtern standen – die da nicht hin gehörten. Die genauere Untersuchung ergab: Das waren alles „Automatische Trennstriche“ (so die Bezeichnung im Suchen/Ändern-Pod; in MIF als \x06 kodiert).
Meine Vermutung: Die Übersetzung wurde irgendwo im Prozess mit einer Textverarbeitung bearbeitet, in dem automatische Silbentrennung eingeschaltet war, anschließend sind die Trennzeichen nie ausgefiltert worden sondern wurden durch alle Stufen (Translation Memory) bis in die MIF weitergegeben.
Meine Frage: Ist das als Bug zu sehen, dass FM diese automatischen Trennstriche als generell druckbare Zeichen interpretiert?
Johannes Graubner (Transcom)
Hallo Michael,
> Warum ist die Datei nicht postwendend wieder
> beim Übersetzungsdienstleister gelandet?
Das größere Problem: Es muss erst mal erkannt werden, dass die Übersetzung fehlerhaft ist. Bindestrichen zwischen Worten sind ja nicht per se falsch. Optisch unterscheidet sich \x06 nicht vom Bindestrich. Dies macht den Fehler so tückisch. (Ein Fragezeichen für ein im Zeichensatz nicht kodiertes Zeichen wäre mir lieber gewesen.)
Und: Ja, natürlich prüft der Übersetzungsdienstleister jetzt seine Prozesse, der hat immerhin eine eigene Technikabteilung für so etwas.
> Das Zeichen \x06 gibt es schon seit Anbeginn in FrameMaker, es taucht aber eigentlich gar nicht auf,
Doch, taucht auf: Das Zeichen für den automatisch beim Zeilenumbruch von FM gesetzten Strich ist ebenfalls \x06 (zumindest findet die Suche nach dem „Autom.Trennstrich“ sowohl das Zeichen, das in MIF mit \x06 kodiert ist, als auch den automatisch gesetzten Trennstrich).
> Für \x06 gibt es keine Unicode-Entsprechung,
Aber warum fügt Trados das dann in die MIF-Datei ein?
> Aber wie auch immer, kann man von einer SW verlangen mit jedem zugelieferten
> Müll zurecht zu kommen?
Ich erwarte durchaus, dass nicht druckende Zeichen nicht gedruckt werden (demnächst wird noch das ASCII-Klingelzeichen 0x7 mitgedruckt?). Wobei \x06 ein Zwitter ist: Am Zeilenende, von der Layoutengine eingefügt, soll es natürlich drucken. Allerdings: Die FM-Layoutengine fügt ein \x06 auch dann ein, wenn schon eines da steht, dann gibt es 2 Trennzeichen, die gedruckt werden.
> Reparatur-Vorschläge (für Heimwerker):
> a) Alle \x06 durch \x04 ersetzen…
> b) Alle \x06 löschen
Wie schon notiert: Suchen nach „Autom. Trennstrich“ / Ersetzen durch „“ (nichts) löst das Thema – wenn man es als Problem erkannt hat, siehe oben. Das ist, zumal wenn man die übersetzten Dateien schon weiter verarbeitet hat, der deutlich effektivere Weg, als sich neue Dateien von der Übersetzungsagentur kommen zu lassen. Vom Ersetzen gegen \x04 rate ich ab:
· Kann ich mir sicher sein, dass die Trennfuge korrekt ist? (Es ist vermutlich ein automatisch eingefügtes Zeichen, das also nur so korrekt ist, wie die dahinter stehende Silbentrenn-Engine gut ist.)
· Das Wort wird nachfolgend von FM nur noch an dieser Stelle getrennt, egal was die FM-Silbentrenn-Engine oder das Benutzerwörterbuch sagen.
Viele Grüße
Johannes
--
Michael Müller-Hillebrand
Am 24.11.2016 um 14:05 schrieb Johannes Graubner (Transcom) <grau...@transcom.de>:> Das Zeichen \x06 gibt es schon seit Anbeginn in FrameMaker, es taucht aber eigentlich gar nicht auf,Doch, taucht auf: Das Zeichen für den automatisch beim Zeilenumbruch von FM gesetzten Strich ist ebenfalls \x06 (zumindest findet die Suche nach dem „Autom.Trennstrich“ sowohl das Zeichen, das in MIF mit \x06 kodiert ist, als auch den automatisch gesetzten Trennstrich).
practice innovation
Das ist ein Bug!!! Aber für mich mal wieder im Prozess und deshalb nicht von FM zu lösen.
Warum?
Vermutlich steht hier schon im verwendeten TM also in der Trados Datenbank Müll drin. Wenn Du das auf FM-Seite korrigierst behebst du das Symtom aber nicht die ursache. D.h. Das TM muss auf übersetzer-seite bereinigt werden, damit das Problem bei der nächsten Übersetzung nicht wieder auftritt.
Selbst wenn hier Trados beim Export ein problem haben sollte (wovon ich mal nicht ausgehe) ist das ein Problem, das der Übersetzer zu lösen hat; er hat ja scheinbar eine Technik und QS.
Kann ja nicht sein, dass hier beim kunden aufwand hoch kommt weil hier ein falsches zeichen aufschlägt, das vom kunden nicht geliefert und gefordert wurde.
Würde er statt einem ü ein u liefern würde das ja auch nicht akzeptiert werden. Bei einem trennstrich ist das auch nichts anderes.
=> schnittstelle im prozess: verantwortung des übersetzers.
Müll geliefert => ablehnung der weiterverarbeitung und rückgabe an den verursacher
Gruss
Markus
Stefan Gentz
Hi Johannes,
das habe ich schon mal gesehen, ist aber schon vieeele Jahre her. Ich vermute mal daher sehr stark, dass es sich dabei um eine fehlerhafte Einstellung im CAT Tool des Übersetzers handelt, zumindest wenn er mit Trados arbeitet. Um es genauer zu sagen, müsste ich wissen, welches System der Übersetzer bzw. die Agentur einsetzt, und wie es konfiguriert ist.
Es gab (gibt?) in Trados in den Filter-Einstellungen für MIF die Möglichkeit, automatisch generierte Trennungen im ausgangssprachlichen Dokument als Tag umzusetzen. Im ganz uralten Trados (zu S-Tagger Zeiten), wurde dann immer da, wo eine automatische Trennung in der MIF ausgezeichnet war ein <:sh> tag eingefügt. (<:dh> war das „Discretionary Hyphen“ (also die manuelle Trennempfehlung in FM), <:nh> (no hyphen) die Trennunterdrückung in FM).
Ich schätze mal, das haben die Programmierer von Trados anno dazumal (vor 20 Jahren?) halt zu „platt“ umgesetzt: alle Arten von hyphens wurden als irgendein tag umgesetzt. Für dh und nh machte das Sinn, für die automatischen Trennungen (die FM eben auch in die MIF schreibt – ja, kann man aus heutiger Sicht diskutieren!) machte es eigentlich nie Sinn. Später gab es dann im S-Tagger explizit die Möglichkeit, die Umsetzung von automatisch erzeugten Trennstrichen in sh Tags auszuschalten.
Sowas in der Art wird auch hier bei Dir die Ursache sein. Selbst SDL Trados Studio hatte mit Trennstrichen noch so eine Probleme. So konnte etwa eine manuelle Trennempfehlung zwar als „-“ dargestellt werden. Wenn man aber die „Sonderzeichen“ allgemein ausblendet blieben sie aber trotzdem sichtbar.
Kurzum, ohne genauere Kenntnis, was an den Übersetzer geliefert wurde (FM? MIF? In welcher Version?), welches Übersetzungssystem in welcher Version eingesetzt wurde, wie dieses System in den Filtereinstellungen für MIF konfiguriert wurde und welche „illegalen“ Prozesse der Übersetzer abweichend vom definierten Prozess vielleicht sonst noch so gemacht hat (da könnte ich ein ganzes Buch drüber schreiben) lässt sich die Fehlerursache nicht klären.
Klar ist aber, dass der Fehler im Prozess bei Agentur / Übersetzer passiert ist. Wahrscheinlich ein Konfigurationsfehler auf Grund mangelnder Prozess- und Toolkenntnis.
Meine Empfehlung: Dem Lieferanten um die Ohren hauen und um Korrektur bitten. Und zwar nicht nur, damit Du weniger Arbeit hast, sondern auch, damit das TM nicht diesen Müll enthält (und es später keine Matches mehr gibt, und für Dich die Übersetzung teurer wird).
--
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "frameusers-de" sind.
Johannes Graubner (Transcom)
Hallo Stefan,
danke für Deine ausführlichen Erläuterungen. Ich habe sie leicht gekürzt an den Übersetzungsdienstleister weiter gegeben, sie werden ihm hoffentlich bei der bereits angelaufenen Fehlersuche helfen.
Während ich den Standpunkt verstehe, dass die Fehlerursache im Prozess außerhalb von FM liegt, denke ich trotzdem, FM sollte dem vorbeugen, dass sich der Fehler auf die Ergebnisse in FM auswirkt:
In der Programmierung gibt es die Forderung, dass ungültige (Zeichen in) Eingaben ausgefiltert werden, ehe diese weiter verarbeitet werden – vorrangig um ein Ausbrechen des Benutzers aus dem vorgegebenen Rahmen mittels kritischer Zeichenketten zu verhindern. Ähnlich sehe ich die Situation hier: Ungültige Eingaben (z.B. \x06) dürfen gar nicht erst in den weiteren Prozess gelangen, sind beim MIF-Import zu filtern. Die Gefahr von Angriffen auf meinen Rechner ist bei dem automatischen Trennzeichen zwar vermutlich gering, aber die Übersetzungen sind „spoiled“, ohne dass ich als Layouter das erkenne – das Trennzeichen wird als normaler Bindestrich dargestellt.
PS: Der Übersetzungsdienstleister liefert mir seit Jahren Übersetzungen. \x06 in MIF-Dateien lieferte er mir erstmalig vor etwa einem halben Jahr, erst beim 3. betroffenen Projekt fiel es auf.
PPS: Abgesehen von den automatischen Trennstrichen habe ich mich ja wie üblich gefreut, wie unkritisch es ist, Übersetzungen in FrameMaker durchzuziehen. (Ok, ich habe noch ein paar unterstützende Skripte, die auch sprachspezifische Probleme lösen bzw. typische Fehler im TM-Prozess beheben).
Viele Grüße
Johannes
practice innovation
Hallo Johannes,
Ø In der Programmierung gibt es die Forderung, dass ungültige (Zeichen in) Eingaben ausgefiltert werden, ehe diese weiter verarbeitet werden – vorrangig um ein Ausbrechen des Benutzers aus dem vorgegebenen Rahmen mittels kritischer Zeichenketten zu verhindern.
Das kann ich nicht ganz nachvollziehen. Es gibt hier keine Benutzerschnittstelle. MIF ist ein Austauschformat zu dem es eine Spezifikation gibt. Das MIF wird (hoffentlich) von Software erzeugt und gelesen. Beide Beteiligten haben sich an diese Spezifikation zu halten.
Das von Deinem Übersetzer gelieferte MIF ist formal korrekt und entspricht der Spezifikation. Woher soll jetzt FrameMaker wissen, dass das gelieferte Zeichen \x06 eigentlich \x04 sein soll oder eigentlich gar nicht gewünscht ist. Das ist das Gleiche, wie in meinem Beispiel mit dem gewünschten „ü“ und dem gelieferten „u“. „\x06“ ist ein gültige Eingabe, wie auch das „u“, nur eben nicht die, die speziell Du Dir erwartest. FM kann das nicht erkennen, deshalb ist das ausschließlich und alleine in der Schnittstellung „Übersetzungsprozess“ zu lösen.
Es gibt also im Prozess nur 3 Möglichkeiten, das Problem zu lösen:
1. Der Übersetzer prüft und korrigiert seine Prozesse/Daten, so dass das künftig wieder korrekt geliefert wird (was ja gerade passiert)
2. Du tauscht die fehlerhafte Ressource „Übersetzer“ in Deinem Prozess durch eine funktionierende Ressource aus
3. Du ziehst Dir den Schuh an, und erweiterst Deine Skriptsammlung um eine Funktion, die den Input auf dieses Problem prüft und ggf. korrigiert
Um so etwas zu erkennen, braucht es künstliche Intelligenz, und die muss weiter entwickelt sein, als es heute der Fall ist. Vielleicht kann das ja FrameMaker 42 einmal leisten. Beim aktuellen Releasezyklus von ca. 1,5 Jahren, wird das dann in ca. 42 Jahren der Fall sein, was Hoffnung macht ;-)
Schön Grüße
Markus
practice innovation
Hallo Stefan,
aber vielleicht komme ich doch noch mit Johannes zusammen, in dem ich mich mal dem Thema von einer anderen Seite nähere:
FrameMaker verwendet gerade für Sonderzeichen (Wahlweiser Trennstrich, Non-Breakable-Space, etc.) immer noch die interne FrameRoman Kodierung, im Zeichencode-Bereich <32. Siehe (character_sets.pdf).
Das macht immer wieder Probleme, da diese Zeichen nicht intern bleiben sondern an manchen Stellen noch immer nach außen gegeben werden.
1. Beispiel: Wahlweiser Trennstrich (FrameRoman \x04 ; Unicode \xAD)
Wenn man dieses Zeichen, was eigentlich Unicode „0xAD“ entspricht, im XML nach außen geben will, funktioniert das im Standard nicht. Man muss immer noch den von MMH beschriebenen Workaround gehen (http://cap-studio.de/wp/index.php/info/framemaker/bedingte-trennung-im-xml-roundtripping/)
Hier würde ich mir erwarten, dass FM \x04 und \xAD gleichwertig behandelt. Das gilt dann auch für alle anderen Sonderzeichen in dieser Kodierung, für die es eine Unicode-Entsprechung gibt.
2. Umbruchgeschütztes Leerzeichen (FrameRoman \x11 ; Unicode \xA0)
Tippt man „strg+Leertaste“ erhält man das Zeichen \x11, was dann bei eingeschalteten Steuerzeichen auch entsprechend mit einem Symbol dargestellt wird. Tippt man hingegen „Alt+0160“ (oder holt sich das Zeichen aus der Zwischenablage) sieht man hier im FM bereits ein unterschiedliches Verhalten. Obwohl es eigentlich das gleiche Zeichen ist (gleiche Bedeutung hat) stellt FM das unterschiedlich dar.
3. Tabulator (FrameRoman \x08 ; Unicode \x09)
Möchte man z.B. über ein Script einen Tabulator setzen, muss man das im Script mit „0x08“ tun anstatt wie erwartet mit „0x09“. Setzt man „0x09“ erhält man einen weichen Zeilumbruch, da dieser in der FrameRoman Kodierung auf \x09 (Unicode \x0A) liegt.
Es gibt hier sicherlich noch mehr Bespiele, aber ich denke die Problemstellung sollte klar werden.
Wenn FM 20xx auch diese Stellen vollständig auf Unicode umstellt und diese Kodierung zumindest nach außen nicht mehr unterstützt, könnte das Problem von Johannes (vielleicht) in Zukunft auch gelöst sein, denn damit sind in MIF 20xx Zeichen <32 konsequenterweise auch nicht mehr erlaubt/spezifiziert, und FM könnte zumindest den Import verweigern oder - etwas benutzerfreundlicher - die Fehler protokollieren.
Achtung: evtl. Abwärtskompatibilität beachten.
Gruß
Markus
Johannes Graubner (Transcom)
Hallo Markus,
> Beide Beteiligten haben sich an diese Spezifikation zu halten.
> Das von Deinem Übersetzer gelieferte MIF ist formal korrekt und entspricht der Spezifikation.
Das ist genau die Frage. Soweit ich die Diskussion bislang verstand, ist \x06 eben gerade kein Zeichen der MIF-Spezifikation. Und wenn ich mir die MIF-Referenz von Adobe anschaue (http://help.adobe.com/en_US/FrameMaker/9.0/MIF_Reference/MIF_Reference.pdf#page126; das jüngste Dokument, das ich dazu finden konnte), dann kommt darin weder „\x06“ noch „automatic hyphen“ vor (siehe http://www.frameusers.com/uploads/2016/02/FM8_framemaker_character_sets.pdf#page=22 , Seite 22). Auf Seite 126 werden zwar verschiedene Hyphens gelistet, aber nicht dieses.
Also:
· Ja, es ist ein Fehler, dass irgendwelche (Übersetzungs-)Werkzeuge \x06 in die MIF-Datei schreiben.
· FrameMaker sollte unzulässige Zeichen aus der MIF-Datei ausfiltern.
Anmerkung zu „Es gibt hier keine Benutzerschnittstelle.“ (von der Zeichen auszufiltern wären): Penetrationstests werden typisch automatisiert durchgeführt: Von Software, die die kritischen Zeichenketten liefern. Auch typische lokale Angriffe auf Deinen Rechner erfolgen mit Software, die z.B. mit ausgeklügelten Softwarestrings, die an bestimmte Programme auf Deinem Rechner geschickt werden (wozu sie typisch Rechte haben), versucht aus dem Kontext des Programms auszubrechen (und auf Rechteebenen zu kommen, die sie eigentlich nicht mehr haben). Warum sollte nicht jemand auf die Idee kommen, mit MIF-Dateien Lücken im FrameMaker auszunutzen?
PS: Ich stimme Dir zu, dass FM das Zeichen \x06 nicht einfach ausfiltern dürfte, wenn es der Spezifikation entspräche. Nur dann müsste man fragen, ob die Umsetzung, das Zeichen im Druck als Bindestrich darzustellen (ohne nach dem Zeichen in eine neue Zeile zu umbrechen), korrekt ist.
Viele Grüße
Johannes
--
practice innovation
Hi Johannes,
nur weil das Zeichen nicht in der Spezifikation aufgeführt ist, heißt es ja noch nicht, dass FM das nicht unterstützt und nicht zum MIF-Standard gehört.
Vielleicht ist es ein FM internes Zeichen das nicht dokumentiert werden soll?
Vielleicht wurde es aber einfach nur vergessen zu dokumentieren? Unwahrscheinlich; aber soll schon mal vorgekommen sein ;-)
Vielleicht liegt es auch daran, dass es seit FM9 keine neue Version des character_sets.pdf gibt?
Vielleicht ist \x06 auch nur ein Überbleibsel aus längst vergangenen Zeiten, was beibehalten wurde um Abwärtskompatibilität herzustellen und mittlerweile einfach nur deprecated it.
Wer weiß?
Sei’s drum… Meiner Meinung nach kann/muss das nicht von FM verifiziert werden…
Deine „Sicherheitsbedenken“ sind auch sehr weit hergeholt, zumal sich dieses Zeichen (auch in Kombination) nirgendwo negativ auf Sicherheit auswirkt und auswirken kann. Deshalb muss das auch aus diesem Aspekt heraus nicht verifiziert werden.
Wenn ich Dich aber ärgern möchte kann ich das mit dem MIF ganz einfach tun und bin Standardkonform. Beispiel? Ich liefere Dir ein MIF und ziehe darin einen Postscript-Rahmen mit der Größe 0px auf 0px auf und verpacke darin ein schönes Postscript, mit ein bisschen Werbung oder sonstigen Schönheiten für die PDF Generierung. FM kann auch das bis zur Version 42 nicht verifizieren. Hier dann viel Spaß beim Fehlersuchen, wenn’s dann mal auffällt.
Es ist müßig das weiter auszuführen, da das Problem ganz einfach (oder auch nicht) im Prozess zu lösen ist.
Schöne Grüße und schönes Wochenende
Markus