Work environment and requirements
The prospective contractor needs to be able to be in touch with our Workflow Consultant in New Zealand, but also with our IT Team in Romania for the initial development of the specs and the design.
Project Situation
We have a group of clients who use a particular software to prepare their product. We are going to create a workflow that is going to add the translations of selected data into the native XML file.
File transfer
The XSLT solution described below will be connected to existing applications and workflows. Usually clients submit source files in a particular way (eg. upload to FTP, REST or email attachment) and receive them back when they are translated.
In this workflow source files are received, prepared (as described below), and then submitted to the translation environment (again in a specific way). After translation is completed, the File For Translation (FFT) will be resubmitted to the application and the target file is created.
That means that the XSLT application could either be stand alone or integrated in our existing file filter application for pre- and post filtering of files.
Rough outline of the file structure, the envisaged file preparation and the post translation work:
Relevant file structure of client’s native XML file
The file contains all metadata necessary for the client’s product. It is important not to interfere with the other data.
The client’s language relevant content is always element text preceded by an attribute xml:lang=”xx-YY”.
Here an example for text that we are looking for:
///<labels context="LABEL">
<text context="QUESTION" xml:lang="en-US">Text for translation</text>
</labels>
The client’s native xml format has already some multilingual content drawn from the client’s database. If this is the case, then the existing translations follow immediately as sibling.
///<labels context="LABEL">
<text context="QUESTION" xml:lang="en-US">Please select one</text>
<text context="QUESTION" xml:lang="it-IT">Risposta singola</text>
</labels>
If there are more languages, then they will follow on each other - based on the English source text (note that there are “ANALYSIS” attributes too - but usually we most likely deal with “QUESTION” attributes (tbc!):
<text context="QUESTION" xml:lang="en-US">Serial number</text>
<text context="ANALYSIS" xml:lang="en-US">Serial number</text>
<text context="QUESTION" xml:lang="zh-CN">号码</text>
<text context="ANALYSIS" xml:lang="de-DE">Seriennummer</text>
<text context="QUESTION" xml:lang="de-DE">Seriennummer</text>
<text context="ANALYSIS" xml:lang="en-GB">Serial number</text>
<text context="QUESTION" xml:lang="en-GB">Serial number</text>
<text context="ANALYSIS" xml:lang="es-ES">Número de serie</text>
<text context="QUESTION" xml:lang="es-ES">Número de serie</text>
<text context="ANALYSIS" xml:lang="fr-FR">Numéro de série</text>
<text context="QUESTION" xml:lang="fr-FR">Numéro de série</text>
The languages for the translation project are being stipulated at the beginning of the project.
For the following, let’s assume the client stipulated the target languages (e.g. it-IT and zh-CN)
File preparation for translation
Roughly, the process will look like this:
* extract all existing translations into a separate TMX file ([login to view URL]). It will be specified at some later stage if this has to be one TMX file for all language combinations, or one TMX file per language combination.
* extract all English source strings without translations and
* create one XML File For Translation (FFT) per language for internal use
* each FFT file will contain the target language markup with a copy of the English source strings e.g. the Italian FFT will look like this before translat
This matches me in two important ways:
* I am based in New Zealand
* I have extensive XSLT experience with language text files, with a major printed dictionary publisher.
Please see my PM for more details.