KategorieSprache

SDL: XML-Filter anlegen

Lange hat die Verwendung eines wirklichen XML-Filters wenig Sinn gemacht. Zu aufwändig war es und das gleiche Resultat hat man mit einem einfachen Textfilter auch hinbekommen.

Jetzt hat sich das Ganze aber geändert. Neu kann Studio auch die maximale Länge eines Strings überwachen. Das bedeutet, dass der Softwareentwickler in seiner Umgebung eingeben kann, wieviel Platz es im Dialog hat und diese Information dem XML mitgeben. Und diese Information wird in Studio nun ausgewertet und überwacht. Deshalb sind die Zeiten vorbei, wo die Erstübersetzung nochmals an den Übersetzer musste, weil diese unmöglich im Dialog oder Menüfenster Platz hatte.

Da ich die Erfahrung gemacht habe, dass SDL keinen Filter von grundauf kostenlos erstellt, sondern dies nur über den überteuerten Professional Service anbietet, biete ich hier die kostenlose Anleitung, wie vorzugehen ist.

Ich zeige die Einstellungen in SDL WorldServer. In SDL Studio ist dies gleich, teilweise sehen die Fenster einfach unterschiedlich aus. Ich habe es nur soweit dokumentiert, wie ich es selbst benötige, um einen weiteren Filter konfigurieren zu können.

Der Aufbau der XML-Datei

worddav8f6e66f8846cc58db3c49d6dae09becf(1) Der obligate Header
(2) Das Rootelement, das der Erkennung der XML-Datei dient und auch gleich den Sprachschlüssel der Quelldatei beinhaltet. Dieser Sprachschlüssel wird von Studio dann in die Zielsprache geändert.
(3) Medaten wie Ident=“ “ oder ContextHint=“ „, welche ausgeblendet werden
(4) maxlength limitiert die Zeichenzahl im Zieltextsegment
(5) Der eigentlich zu übersetzende Text

Filter in WorldServer

Der neue Filter ist vom Typ: Custom XML Studio File Type

worddav09672b060c3d782a3409d47f695969f3

Das Basiselement ist das Element, mit dem ein Parser das XML identifizieren kann. Leider ist diese Funktion bei WorldServer 10.4.2 noch nicht implementiert. In Studio funktioniert es und man kann mehrere MIME-Typen mit *.xml angelegen. Bei WorldServer geht dies nicht und bedeutet, dass pro XML-Typ ein anderes Dateiformat gewählt werden muss.

worddave2bd2b61f789c0e4a26fa5b4b3eb1906

Im Reiter «Parser» stehen alle Regeln, nach denen der zu übersetzende Text und Metadaten gefiltert werden.

worddav02ab8fe9375cae9431052e066c6e7bbf

Die ersten drei geben die Struktur an und die letzten vier Element die Metadaten

worddav7001fe912a2928ad4c8c3384ba1da523worddavfb6751476659f19a78ffd69c944fd30bworddav275b7a70115ebfd6af841290dcbec837

Im Element «Item» ist das Hauptelement mit den Inhalten drin.

worddav2e1c9d2e6f579767ad25d19c08fd987f

(1) Beim Anklicken von [Bearbeiten…] bei Struktur-Info wird der Dialog für die «Eigenschaften der Strukturinformation» angezeigt.

worddav45779a352226896b32534b27163d1330

Diese muss wie folgt angelegt werden.

worddav6e59888a09ed289c7d30e520893698a7

(2) Unter «Regel bearbeiten» [Erweitert…] anklicken. Dort muss noch das Element für die maximale Länge definiert werden. In diesem Fall ist es @maxlength.
Zusatzinfo: «maxlenght=“0″» läuft ohne Fehlermeldung durch den Parser, aber in Studio wird dann eine Längenbeschränkung von 0 angezeigt. Deshalb sollte in diesem Fall «maxlength» gar nicht angegeben werden.

worddavc0e45f45f378ab5453910d3c93fac1b3

Als letztes sind noch die Attribute zu kennzeichnen, welche nicht übersetzt werden. Leider können diese nicht als Attribut und „Nicht zu übersetzen“ angelegt werden. Es muss ein Umweg über die Erfassung als XPath erfolgen. Ich nehme an, dass dies ein Bug von SDL WorldServer ist, sonst kann ich mir einen solchen Blödsinn nicht erklären.

worddav3e835db6a92d3f0a1561705f0fda271eworddav34cbdf89efec39128c57c0f547cf7a2dworddav09cb946fd0ad884897144982ac1005e2worddav71d17cec155b022b6e2cb4fbe34f759a

Hier die Entitys, welche umgewandelt werden sollen. Dies betrifft aber nur den zu übersetzenden Text.

worddav9a9f9f6c82f5c6a256e2e38938c0d659

Beliebigen Präfix wählen und die URL von w3 eingeben.

worddav9f3dc4575087755828394bd42e116ee7worddavb4b2f4aa78f1559a0723c310d0fdf3d1worddav9df4e20d828e0d9268bd1edb4a01c5c1

Im «Embedded Content» können RegEx-Filter konfiguriert werden, um Platzhalter und sonstige Ausdrücke zu sperren.

worddavd3defc1bdc16eb17270066d47c8984fe

Man unterscheidet zwischen Tag-Paaren. Also alles was zwischen diesen Tag liegt, wird für die Übersetzung gesperrt.

worddav2bd90c1d6b9165a78ab7f2ba945dfb51

Und Platzhaltern, welche einen Teil/eine Stelle im Text definieren. In der Regel sind dies Variablen.

 

Zum Schluss noch etwas…

Auf ein weiteres Problem muss man auch noch achten. Es geht um die Verarbeitung mehrerer XML-Filter. SDL Studio kann anhand des Rootelementes selbst entscheiden, zu welchem Filter eine XML-Datei passt. SDL WorldServer kann dies nicht, obwohl diese Information im Filter definiert werden muss. Nun, wenn diese Information nicht ausgewertet wird, wieso muss man diese dann erfassen?

Das Resultat ist aber, dass SDL WorldServer in der aktuellen Version 10.4.4 nur eine einzige XML-Datei mit der Dateierweiterung .xml verarbeiten kann. Eine weitere XML-Datei muss eine andere Dateierweiterung haben oder zu einer anderen Filtergruppe gehören, mit dem Resultat, das der Benutzer dann den richtigen Filter auswählen müsste… Was mich verärgert, ist der Fakt, dass Studio das Problem nicht hat und mehrere XML-Dateien anhand des Rootelementes unterscheiden kann. Man beachte auch, dass ich Studio ab 99€ bekomme und WorldServer etwa das tausendfache kostet. Ein Lösung für WorldServer 11.0 wurde mir auch nicht zugesichert.

 

.over-and-out

 

 

 

 

 

«Leichte Sprache» in der Kantonsverwaltung St. Gallen

Nun will die Verwaltung des Kanton St. Gallen etwas Gutes tun und hat eine erste Botschaft zusätzlich in «Leichter Sprache» publiziert. Soweit so gut.

Diesen Text habe ich mir mal angeschaut und bin der Meinung, dass es hier noch einiges an  Verbesserungspotential gibt. Aber fangen wir mal von Vorne an, bei den Zielgruppen. Hier versucht man vier Personengruppen damit abzufangen: 1. Personen mit Lernstörungen, 2. Analphabeten, 3. Pensionäre und 4. Ausländer. Wenn ich den Text anschaue, dann ist dieser Text aber eher für eine 5. Personengruppe geschrieben, nämlich solche mit speziellen Bedürfnissen. Das soll nicht herablassen tönen, denn auch Personen mit speziellen Bedürfnissen soll man erreichen können.

Hier der Grund, wieso ich bei den anderen vier Personengruppen aber denke, dass diese Texte unpassend sind:

  • Personen mit Lernstörung oder Analphabeten haben nicht per se ein intellektuelles Defizit. Wenn ich schlecht lesen kann, dann spielen die verwendeten Wörter eine sekundäre Rolle. Natürlich ist es ein riesiges Problem, wenn es sich um Amtsdeutsch handelt, mit Schachtelsätzen und unbekannten Fremdwörtern handelt, aber dazu noch später.
  • Pensionäre werden auch nicht per se zum Zielpublikum dieser Art von Publikation. Diese sehen mit den Jahren vieleicht schlechter, aber sonst sind die meisten im Kopf noch fit wie ein Turnschuh. Demenz ist ein anderes Thema, aber da gehören sie dann wieder zur fünften Personengruppe.
  • Ausländer: Tja, da ist die Schweiz aus meiner Sicht zu gutmütig. Ein Grundverständnis der (Hoch-)Sprache des Landesteiles wo man lebt, sollte aus meiner Sicht nach 6 Monaten ein Muss sein… Aber dazu möchte ich mich nicht weiter äussern, da ich nicht in die rechte Schublade gesteckt werden will, wo ich mich definitiv NICHT sehe!

Jetzt aber nochmals zu den Inhalten. Hier fehlt mir noch eine Strukturierung durch Überschriften. Mindesten eine Auszeichnung solcher. Eine Seitenweise Auflistung von ein-, zweizeiligen Absätzen entspricht nicht meinem Verständnis eines gut lesbaren und verständlichen Textes.  Wieso man bei Aufzählungen auf Aufzählungszeichen verzichtet, ist mir auch schleierhaft, denn dadurch wird der Text schwerer verständlich. Nun ja, vielleicht können Personen mit speziellen Bedürfnissen mit Aufzählungszeichen vielleicht nichts anfangen, aber ganz sicher würde es den Zielgruppen 1 bis 4 helfen.
Soweit meine Gedanken zu den paar Seiten Text, den ich dafür analysieren konnte.

Trotzdem habe ich noch etwas: Was belustigend ist der Fakt, dass der Kanton St. Gallen die sonst verwendete Sprache «Schwere Sprache» nennt… Nicht «normal», sondern «schwer»! So und da fühle ich mich als Nicht-Jurist und nicht Staatsangestellter ausgegrenzt. Also verstösst die «Schwere Sprache» gegen die gesetzlich geforderte Inklusion.
Und deshalb hier mein Vorschlag: Wieso kreiert man nicht eine «Normale Sprache» für alle amtlichen Dokumente? So wie eine Person mit speziellen Bedürfnissen ein Problem beim Verstehen von «normalen» Texten hat, so hat die Mehrheit der Schweizer auch ein Problem beim Verstehen des Amtsdeutsch der «Schweren Texte». Sprache wandelt sich, wobei die Amtssprache immer irgendwie einige Dekaden nachhinkt. Oder sehe ich dies komplett falsch?

Kann heute überhaupt noch jemand richtiges Deutsch?

Eigentlich wissen wir ja alle, dass die Qualität von Gratiszeitungen nicht über alle Zweifel erhaben ist. Und ich rede ja nicht einmal über die wichtigen „Stories“, welche da plattgetreten werden. Heute sind mir aber beim Lesen von drei Beiträgen soviele Fehler wortwörtlich in die Augen gesprungen, dass ich hundertprozentig sicher bin, dass diese Texte noch nie ein Lektor geprüft hat. Wäre es so, dann würde ich die Personen sofort freistellen. Na gut, meine Texte sind auch nicht immer fehlerfrei, aber a) verwende ich zum Schreiben einen „dummen“ Texteditor ohne Korrekturfunktion, b) hat auch keine Zweitperson meinen Text korrigiert, c) ich in der Regel nur schnell meine Gedanken zu einem Thema loswerden will und d) ich damit auch kein Geld verdiene.
Aber nochmals zum Thema: Liebe Gratiszeitungen! Wenn Ihr schon kein Geld für ein anständiges Lektorat ausgeben wollt, dann baut doch eine Funktion ein, damit die „Crowd“ Korrekturen vornehmen kann. Und wenn ein Fehler mind. 10x korrigiert wurde, dann sollte es sich ein Redaktor doch mal anschauen… Nur so eine Idee, würde aber extrem innovativ rüberkommen und ihr könnt Eure Kosten für die Redaktion nochmals senken, resp. noch unqualifiziertere Redakteure auf Beitragsbasis anstellen.

.over-ende-und-out

© 2024 hacker.li

Theme von Anders Norén↑ ↑