KategorieSDL

Export Excel to XML including length limitation and comments

In my previous post I showed how to handle XML comments in SDL Studio. Everything builds on my “standard” XML file with a very simple structure.

As you know life is sometimes not so easy and many people can’t create a XML file from their preferred tools. Most the time we actually get Excel files for translation. Recently there was the demand also to enforce length limitation in Excel sheets.

The good news is that this can be achieved quite easily, if you know how to do it. The ingredients for this are a XML file in the standard you would like to have and the Excel file itself.

 

The XML file has the known structure and one <Item> line would be enough.

 

Open the “Developer” tab in Excel.

 

Click on “Source”. The XML Source window opens on the right. Click “XML Maps…”.

 

Click “Add…” and choose the sample XML “Sample.xml”. Close with OK.

 

The XML structure is shown.

 

Now you need to grab the XML elements in the right window and place it on the corresponding cell in Excel.

So in this sample, drag “Ident” and drop it in cell A1. Grab “maxlength” and drop it in cell B1. Grab “<value> and drop it in cell C1. Grab “Comment” and drop it in D1.

 

 

The Excel should look like this:

 

Go back to the “Developer” tab and press “Export”.

Store the XML with any name you like.

Finished! Almost…

 

Open the XML to verify the content. The content from the Excel file is now in the XML.

 

Now you can process the file in Studio with the filter described in the last post.

 

If required, change the mapping before the import. My sample Excel has a different column for the target. So right-click on “<value> and choose “Remove element”. Then drag “<value>” and drop it on target.

 

 

The Excel looks now like this:

 

Import the translated XML file.

 

Done!

Here are the sample files: EXCEL_Sample

 

.over-and-out

XML comments in SDL Studio

How to parse a XML file to interpret a maximal file length was described in an earlier post. We continue to work with this file. A sample XML is included in the zip-archive at the end of this post.

Now we are looking how to show comments in this file in Studio, so the translators can see the additional information.

A good introduction into this topic you can find in Paul Filkin’s Blog https://multifarious.filkin.com/2013/02/22/translate-with-style/.

As he states, in Studio there is only the possibility to show the comments in the “Preview” pane. If you don’t have any stylesheet referred, then the XML source code is shown. As you might know translators, the minority are good with code, so they will struggle to find the information. Especially in a huge document, it will be very painful. But Paul has shown in his blog how to format the preview and only show the required information.

With this help I created a XSL stylesheet (Style.xsl) which will work with my XML file.

Now you just need to refer to the XSL file in the Studio filter settings. By the way: Once you selected the XSL file, the file is uploaded to the filter. Any later changes of the XSL file need to be uploaded again.

The finished filter for Studio (XML-Lenght_limited-Comments_in_preview.sdlftsettings) is also included in the zip-archive at the end of this post.

So, when you create a new project in Studio and import the XML, the preview in Studio looks like this:

 

You can open the preview pane on the right-side tab or in the top menu.

The next step is to export the filter settings (XML-Lenght_limited-Comments_in_preview.sdlftsettings). We can use this file to create the filter in WorldServer. Unfortunately, after the import to WorldServer, it shows that the “Preview” setting is not available. This is another misalignment of the file type filters in Studio and WorldServer.  But the XSL is still there…

Hi Ray! One more thing I need to get fixed… 😉

 

When you create now a Translation Kit from WorldServer and open it in Studio, it will show the comments in the way we had planned in the beginning.

If, one day SDL, will align their filters, then we can even change the XSL sheet directly in WorldServer. One day…

Download zip-archive

 

. over-and-out

 

 

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.

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

 

 

 

 

 

© 2024 hacker.li

Theme von Anders Norén↑ ↑