SchlagwortXML

SGML Filter for SDL Studio 2017 and/or WorldServer 11.1

To create a filter for SGML files can be a difficult and expensive task, if you don’t know how to handle those files. I can tell this from experience. First I made the misinterpretation that SGML files are similar to XML files and tried to build something around an XML filter. I didn’t work! Why? Because the SDL tools are very strict in this matter and since the SGML might have the same structure as a XML file, the header and the doctype declarations are not the same at all. So the tools denied the creation of such a filter.

The next choice was my favorite: The RegEx. With the RegEx capability of Studio and/or WorldServer you can create filters for almost any files. But unfortunately in this case the file was so strange structured with returns in the tags, that this also did not work or just with some strange workarounds which also meant to have only a 99% solution. And when it is about translation handling, 99% is not good enough.

Only when I pointed my problem to the SDL support, they came up with another solution and it worked.

The solution is a HTML5 filter. It can do much more than HTML. When you create a new HTML5 filter in SDL Studio 2017.

You start with creating a [New…] filter and choose HTML.

Give the files a unique name, a unique file type identifier and add the correct file dialog wildcard expression (e.g. *.sgm)

Choose „Define HTML elements based on SGML…“ and point it to a reference file.

 

SDL Studio identifies automatically all elements from the reference file. Here I think SDL did a great job!  Go to the next window. You just need to define which elements are translatable and which ones not. Just click on the values and choose the correct one.

Open the reference file, copy the doctype tag and paste it into the dialog.

Leave it as it is.

I choose that everything stays as it is. So „preserve“ and „Do not change“ are our friends.

I choose that everything stays as it is. So „preserve“ and „Do not change“ are our friends.

Done!

Now the filter is working and SMGL files can be processed.

 

.over-and-out

 

SDL WorldServer: XML-Transformation über XSLT

WorldServer hat bereits eine automatische Aktion “Apply XSLT”. Diese sollte – wie ihr Name es verspricht – eine XSLT-Transformation an den Quelldateien durchführen. Leider klappt es aber nicht auf Anhieb, denn der Schritt ist nur als ‚Sample‘ konzipiert, das je nach Bedürfnis angepasst werden muss; in der Regel möchte SDL solche Anpassungen über den Professional Service anbieten.

Es geht aber trotzdem. Das Hauptproblem liegt darin, dass Ausgangsordner für sowohl Input- wie auch Output in der Action “Apply XSLT” nicht identisch sein dürfen. Deshalb muss zunächst die unkonvertierte Datei in den Zielordner kopiert werden und dann aus dem Zielordner in den Ausgangsordner mit XSLT zu transformieren. Das scheitert aber daran, dass es im Code der Automatic Action “Apply XSLT” eine Klausel gibt, die das Auslesen aus dem Zielordner und das Schreiben in den Ausgangsordner verhindert. Hier der entsprechende Code:

/*
* Sanity check the params: don’t let the user read from target
* and write to source.
*/
if (readFrom.equals(TARGET_VALUE) && writeTo.equals(SOURCE_VALUE)) {
return new WSActionResult(WSActionResult.ERROR,
„Invalid configuration: action can’t read from target “ +
„and write to source.“);
}

Die Entwicklung von SDL hat mir (Danke für den super Service!)  die Automatic Action “Apply XSLT” für die SDL WorldServer Version 10.4.4.139  so angepasst, dass das Auslesen aus dem Zielordner und das Schreiben in den Ausgangsordner erlaubt ist. Laut Aussage vom Support soll dies in zukünftigen Versionen von WorldServer dann bereits so “gefixt” sein. Für die aktuelle Installation habe ich dafür vom Support eine neue Automatic Action “Apply XSLT” bekommen (hier).

Die Lösung besteht nun darin vor der XSLT-Transformation zunächst die Ausgangsdatei aus dem Ausgangsordner mithilfe der Automatic Action “Copy source asset to target” zu kopieren.

08-03-_2016_12-59-23

 

Und anschliessend mit “Apply XSLT“ mit den Werten ‚Load XML from‘=Target und ‚Save result to‘=Source zu konvertieren.

Wie man die XSLT erstellen, erläutete ich hier nicht. Interessant ist aber zu wissen, welche Xalan-Version WorldServer https://xml.apache.org/xalan-j/ dafür verwendet und dies zumindest bei Version 11 auch noch so bleiben wird.

08-03-_2016_10-22-17

 

Als der Workflow soweit funktionierte, wollte ich auch noch die Validität der XML-Datei überprüfen, da diese “manuell” aus einer Textdatei zusammengebaut wird.

Um dies zu Prüfen wurde die Automatic Action “Validate XML” in den Workflow eingefügt und eine entsprechende DTD programmiert.

08-03-_2016_10-21-42

Leider reicht der Verweis zur DTD in der Action nicht aus, sondern es muss auch noch die DTD im XML eingefügt werden (leider). In unserem Fall sieht die XML-Datei wie folgt aus:

<?xml version=“1.0″ encoding=“UTF-8″?>
<!DOCTYPE mxml [
<!ELEMENT mxml (#PCDATA)>
]>
<mxml>

INHALT…

</mxml>

 

Resultat:

Ein Workflow, welche die Daten vom Quellverzeichnis in das Zielverzeichnis kopiert, die Gültigkeit der XML-Datei(en) überprüft und danach eine XSLT-Transformation durchführt. Nach der Übersetzung werden die Dateien auch nochmal durch eine XSLT-Transformation gelassen, mit dem Ergebniss, dass der Auftraggeber eine Textdatei zurückbekommt.

Hintergrund:

Dieser Aufwand wird betrieben, da wir in XML-Dateien mit dem Attribut maxlength=”xx” die maximale Länge des Strings im Übersetzungsprozess einfordern können. Dies ist hilfreich bei Software-Strings. In einer Textdatei (wie wir diese aus einem alten Entwicklugnstool bekommen)  kann diese Information aber nicht hinterlegt werden. Deshalb muss aus der Datei zuerst mit dem Einfügen eines XML-Headers und –Footers eine pseudo XML-Datei erzeugt werden, damit diese dann über eine XSLT-Transformation in die passende XML-Datei umgewandelt werden kann.

© 2017 hacker.li

Theme von Anders Norén↑ ↑