Hi Guys,
We are sharing our wild thoughts with a vision to explore the possibilities of the use of OpenXml formats.
In this post we are trying to explore the possible impacts of openXml file formats in the Translation Service Sector.
Machine Translation Service (on-line) till yesterday:
-- When the word document needs to be translated from one language to another,
The end-user has to upload the whole word document to the Translator's location (ftp/http website) to get it translated (along with its formatting preserved).
This added three overheads --
1) Microsoft Word needs to be installed in the Translator's Server for parsing the document for stuffs like bookmarks, contents etc (for extra facilities like custom dictionaries,etc).
2) The size of the doc (lets assume the doc also had images,etc) to be uploaded for translation--when uploading in internet is primely based on the speed of the connection
3) The translator's Engine should load the memory-sensitive word document and then parse its contents for translation
Today with the advent of OpenXml file formats for office
where content separation is the mantra –
Content Files like document.xml, CustomXml files and other html files (referred by altchunk) might have a dramatic impact on translation service sector.
1) Reducing the size of upload: all that the end-user(or the executable running at the end-user's machine) needs to do is --extract files which hold the content to be translated(like document.xml,etc) and upload it to the Translator's website.(Note: the document.xml can be further zipped, to reduce size ,if required).Thus avoiding the unnecessary upload of images,syles,etc.
This makes uploading faster over a low-bandwidth internet connection too, hence reducing the wait-time of the end-user.
2)Develop a custom-parser for content-files(like document.xml):
If the Translator develops a parser to read the contents from the openXml files (like document.xml), then they don't need Microsoft Word Installed in their Server.
3) Speed of translation: Reading the contents from simple text files (xml files) might save time hence impacting the speed of translation.
Now after the translation is complete,On the end-user's machine an executable can replace the translated content files(for example: the uploaded/translated document.xml returned from the Translator) with the original one in the openxml extracts(unzipped docx files). Now zipping the extracts again to docx file will give the translated document that can be viewed by the end user using Microsoft Office.
Hope this helps
Regards
Muthu
Perhaps one can even place translated document.xml files inside the package using the same scheme as resource assemblies. E.g. document.en-EN.xml, document.nl-NL.xml. That way you can build a true multi language document, where the UI application can query the user for the language to display.
My 2 cents.
Wouter
Hi Wouter,
Good suggestion: it will definitely help when the document is translated to multiple languages,for the user can be given an option to select which translated language document ,he wants to view .
Thinking ur way: If "merging" of two document.xml is possible(easy to say than do),then We can also try merging the Original document.xml with the Translated ones. When the user opens the word document,we can try providing the user with an language filtering word- addin on the menu items so that he can view the document based on his preferred language(hopefully bookmarks might help us) .This way he can see/swap between the Original content(native language) and the translated languages in the same document.
Thanks