| Pages in topic: [1 2] > |
Is XLIFF useful to implement for CMS ? Thread poster: Sandeep Kumar Talla
|
|---|
We are using CMS to maintain our portal and now we have to translate into different languages considering localisation. I would like to know whether XLIFF is useful to implement for CMS and if so then what is the life cycle of XLIFF ?
Your comments will be highly appreciated.
Regards,
Sandeep
| | | |
Sonja Tomaskovic (X) 
Germany
Local time: 18:38
English to German
+ ...
| Intermediary format | Sep 14, 2007 |
XLIFF is an intermediary format, i.e. you convert whatever files you have into XLIFF and finally back.
The most significant feature of XLIFF is that it stores both the source text and its corresponding translation in one file. There are a number of free converters online that can transfer your documents into XLIFF and back, however not all source formats are supported (such as Word doc, e.g.).
If your documents are mainly XML files than you should consider to use XSLT t... See more XLIFF is an intermediary format, i.e. you convert whatever files you have into XLIFF and finally back.
The most significant feature of XLIFF is that it stores both the source text and its corresponding translation in one file. There are a number of free converters online that can transfer your documents into XLIFF and back, however not all source formats are supported (such as Word doc, e.g.).
If your documents are mainly XML files than you should consider to use XSLT to convert these forth and back. XLIFF is an open, XML-based standard.
See also http://developers.sun.com/dev/gadc/technicalpublications/articles/xliff.html
HTH.
Kind regards,
Sonja ▲ Collapse
| | | |
Samuel Murray
Netherlands
Local time: 18:38
Member (2006)
English to Afrikaans
+ ...
| Two issues here... | Sep 14, 2007 |
Sandeep Kumar Talla wrote:
We are using CMS to maintain our portal and now we have to translate into different languages considering localisation. I would like to know whether XLIFF is useful to implement for CMS and if so then what is the life cycle of XLIFF ?
I don't know what the lifecycle for XLIFF is, but XLIFF is basically an interchange format. If your relationship with your translators is so close that they use a format that you can export yourself, then there is no need for using XLIFF, in my opinion.
I feel very strongly about making life easy for translators. It too often happens that translators are forced to adapt their methods to the translation management system used by the client. Ideally, a translator should get the source text in a way that enables him to translate it using his favourite tool... not using some strange new tool prescribed by the client.
So the issues are:
* What export format allows you to import translations with minimal effort?
* What export format allows your translators to translate the stuff as easily and quickly as possible?
| | | |
| XLIFF Translator Editor | Sep 14, 2007 |
Sonja Tomaskovic wrote:
XLIFF is an intermediary format, i.e. you convert whatever files you have into XLIFF and finally back.
Kind regards,
Sonja
Hello Sonja,
Thank you for the reply..Well i just downloaded Heartsome XLIFF editor. Now we convert the original file format into XLIFF format, then this XLIFF file is given to the translators. Now once we get back the translated file how it will be getting into original file format ? Hope you understood my question.
Regards,
sandeep
| | |
|
|
|
Samuel Murray
Netherlands
Local time: 18:38
Member (2006)
English to Afrikaans
+ ...
| And what will your translators do with it? | Sep 14, 2007 |
Sandeep Kumar Talla wrote:
Now we convert the original file format into XLIFF format, then this XLIFF file is given to the translators.
And what are your translators going to do with the XLIFF file? Translate it, presumably, but how? To translate a file, the translator needs to open it in some kind of editor. Will you prescribe to your translators which tool they should use to translate it in?
| | | |
| most translation tools support XLIFF but it's a pain if you want to translate it without a tool | Sep 14, 2007 |
Hello Sandeep,
XLIFF is a pretty good format - the best bilingual format I can think of because it is documented - yet most translators are a bit afraid of translating XLIFF, mostly because it's an XML format and there is no easy way to preview the translation. However, in the case of a CMS there is usually no easy way out.
Heartsome made XLIFF the internal file format and others also offer support in one way or another - usually by transforming XLIFF into their interna... See more Hello Sandeep,
XLIFF is a pretty good format - the best bilingual format I can think of because it is documented - yet most translators are a bit afraid of translating XLIFF, mostly because it's an XML format and there is no easy way to preview the translation. However, in the case of a CMS there is usually no easy way out.
Heartsome made XLIFF the internal file format and others also offer support in one way or another - usually by transforming XLIFF into their internal file formats and then back.
If you can make the CMS directly export and import XLIFF, that's fine, otherwise you'll find that manual conversion takes too much time. The translation tools also handle XML, and maybe it's easier to make a simple XML export from the CMS and then import XML back. Text in XML files will be overwritten, but in the CMS you can implement a 'multilingualizer', i.e. if you tell the CMS that this is the German translation, the CMS will insert the German translation to the right places and will not overwrite the English text with the German translation.
The decision on what XML file format to use depends very much on the workflow, and I am sure that translators hate almost all XML file formats but the simplest ones. So the two golden rules: 1. try to minimize manual update work for the administrator of the CMS, 2. try to create as simple XML as you can (or even XHTML - translators tend to like HTML more as it has a preview).
And one more thing: make sure that you also export some context, and not just single sentences. It's not something that translators would require, but if you want to have good quality translations, sending over some strings to translate without any context does not work. (But you have to communicate clearly what to translate and what not to translate and also make sure that the translators don't charge for the word count of the context. Maybe adding the context under a different element or creating two export files, one with context and one without context will help - I'd go for the second solution.)
Regards,
István ▲ Collapse
| | | |
Samuel Murray wrote: Sandeep Kumar Talla wrote:
Now we convert the original file format into XLIFF format, then this XLIFF file is given to the translators. And what are your translators going to do with the XLIFF file? Translate it, presumably, but how? To translate a file, the translator needs to open it in some kind of editor. Will you prescribe to your translators which tool they should use to translate it in?
I bought the XLIFF Editor because of one client and I do not regret it. The volume of work from that client has been growing ever since.
Besides, by using the XLIFF Editor they will support and spread the use of an open standard,which the XLIFF format is.
They can also translate the XLIFF files in TagEditor, but first they will have to preform a copy source to target using an XSLT transformation (to find out why and how, please go to okapitools @ yahoogroups.com).
Before they decide on the tool, they will be wise to compare the prices of both products.
BTW, does each/either of OmegaT/OmegaT+ support the XLIFF format?
Regards,
Piotr
| | | |
Sonja Tomaskovic (X)
Germany
Local time: 18:38
English to German
+ ...
| Convert it back | Sep 14, 2007 |
Now once we get back the translated file how it will be getting into original file format ? Hope you understood my question.
You simply have to convert it back with the help of the XLIFF editor. You do this for all languages separately, i.e. if the document was translated into French, German, Polish and Swedish, then you have to convert it back with the XLIFF Editor one by one.
You should read through Heartsome's documentation and help files, where this procedure is documented somewhere. I am pretty sure it is, I used to work with the XLIFF Editor, and I've done this procedure a hundred of times.
Good luck,
Sonja
| | |
|
|
|
Samuel Murray
Netherlands
Local time: 18:38
Member (2006)
English to Afrikaans
+ ...
| Why... why not? | Sep 14, 2007 |
Piotr Bienkowski wrote:
I bought the XLIFF Editor because of one client and I do not regret it. The volume of work from that client has been growing ever since.
If you are happy, then that is fine. But what if you prefer to use a different tool that doesn't support XLIFF directly, like Wordfast or OmegaT? Then the translator has three options:
* Refuse the job
* Reduce his own productivity by using a new tool
* Hack it and pray (which is what I do)
The point is that XLIFF is a very specialised format that locks the translator in to a specific workflow. Compare XLIFF with a two-column MS Word file, for example. Both achieve the same thing, but the MS Word file is infinitely simpler.
Yes, you can save a lot more information in the XLIFF file, but do translators really need all that information? Here I'm talking about things like whether a translation has been proofread, who translated the segment, how old is the current translation, etc.
I suspect some people believe that using XLIFF will reduce the work of a project manager to that of an office assistant, because everything is contained within the XLIFF file.
They can also translate the XLIFF files in TagEditor, but first they will have to preform a copy source to target using an XSLT transformation.
And now you have two possible scenarios:
* The PM will do the conversion for the translator (which means that using XLIFF doesn't save him as much time as he had anticipated because of additional conversions necessary)
* The translator will have to figure out how to do the conversion himself
BTW, does each/either of OmegaT/OmegaT+ support the XLIFF format?
OmegaT+ is dead. OmegaT doesn't support XLIFF directly, no. You can translate XLIFF in OmegaT, and you can do it safely, but it is a hack (just like when I'm using Wordfast to translate XLIFF).
There is a new, experimental branch of OmegaT which claims to use XLIFF for the TM format, but it is not part of the official development track. To find out more, join the OmegaT dev mailing list and read posts from the past 2 months.
| | | |
Samuel Murray
Netherlands
Local time: 18:38
Member (2006)
English to Afrikaans
+ ...
| Let's make a list of tools that support XLIFF | Sep 14, 2007 |
István Lengyel wrote:
Most translation tools support XLIFF but it's a pain if you want to translate it without a tool.
I'm not sure what you mean by "without a tool". Surely all texts are translated in tools... or do you mean that translators have to use a seperate, intermediary tool to convert XLIFF to something else before translating it?
But I'm concerned about your statement that "most" translation tools support XLIFF. I recently tried a number of tools that claim XLIFF support and found that what you read in marketing brochures don't often square up.
Let's make a list of tools that can be used to translate third-party XLIFF (I'm not talking about tools that can only translate their own XLIFF files):
* Trados (treats it like XML, so pray your filter is correct)
* SDLX (success not guaranteed (they say so themselves))
* Heartsome's tools
* Wordfast and OmegaT (if you're a hacker).
...please add to the list.
==
Previous topics on this:
http://www.proz.com/topic/81604
http://www.proz.com/topic/82579
[Edited at 2007-09-14 21:00]
| | | |
| CMSs support XLIFF | Sep 14, 2007 |
Sandeep Kumar Talla wrote:
We are using CMS to maintain our portal and now we have to translate into different languages considering localisation. I would like to know whether XLIFF is useful to implement for CMS and if so then what is the life cycle of XLIFF ?
Hi,
There are CMS programs that already export documents in XLIFF format for translation. Take a look at Ektron CMS or DocZone.
Regards,
Rodolfo
[Edited at 2007-09-15 01:00]
| | | |
Textklick
Local time: 17:38
German to English
+ ...
In memoriam | Sandeep - are you a translator or an outsourcer? | Sep 14, 2007 |
Sandeep Kumar Talla wrote:
We are using CMS to maintain our portal and now we have to translate into different languages considering localisation. I would like to know whether XLIFF is useful to implement for CMS and if so then what is the life cycle of XLIFF ?
It seems only a while back you were initially interested in free and detailed nformation about XLIFF.
See Sam's quoted links:
http://www.proz.com/topic/81604
http://www.proz.com/topic/82579
I''m sorry if I'm wrong, but shouldn't you be doing your own homework? The Internet is always a good point of departure for such research.
[Edited at 2007-09-14 23:28]
| | |
|
|
|
| Tools that support XLIFF | Sep 14, 2007 |
Samuel Murray wrote:
* Trados (treats it like XML, so pray your filter is correct)
Trados 8 has filters for converting XLIFF to TTX and back.
* SDLX (success not guaranteed (they say so themselves))
* Heartsome's tools
* Wordfast and OmegaT (if you're a hacker).
...please add to the list.
* Transolution
* Lingotek
* Idiom's tools
* Lionbridge's tools
* XML-Intl online XLIFF Editor
There is something you didn't mention: XLIFF was invented by corporations that are the largest translation consumers. Those corporations already have tools for translating XLIFF files and provide them to their freelancers.
In many cases the tools that freelancers have at hand can't handle the format of the source document. A common example is software localization. Source files can be C/C++ programs and a regular CAT program can't handle them. In this case, the best thing that the translation consumer can do is provide the strings in a readable format and XLIFF if the best choice as far as I know.
Translators should take XLIFF as just another document format, like a new version of InDesign or any DTP program. It was mentioned that translators should ideally be able to select their favorite tool and that indeed would be a good thing. However, in the same way that translators ask toolmakers to add support for formats like Office 2007, translators should contact the developers of their favorite tool and ask them to provide proper support for XLIFF.
Regards,
Rodolfo
| | | |
| Try lingotek.com | Sep 15, 2007 |
Hi:
I have been using lingotek and I'm quite happy with the results. I love the freedom of having my projects online because it lets me work on them from anywhere. There you can import a TM or an XLIFF file and work with it as with any other text. They made it free since May 1st, 2007.
Regards,
Dora
| | | |
| the answer depends on YOUR content management system | Sep 15, 2007 |
Hi Samuel, Sandeep and others,
Well I may be talking against my interests because MemoQ currently does not support the translation of XLIFF files directly (a workaround converter is available on the wikibooks site and it is going to become a built-in format in the near future) but I believe that XLIFF is a very good format; however, it should be employed if and only if it makes life easier.
In the complex world of CMSes, translation is only part of the game - the most v... See more Hi Samuel, Sandeep and others,
Well I may be talking against my interests because MemoQ currently does not support the translation of XLIFF files directly (a workaround converter is available on the wikibooks site and it is going to become a built-in format in the near future) but I believe that XLIFF is a very good format; however, it should be employed if and only if it makes life easier.
In the complex world of CMSes, translation is only part of the game - the most visible part in terms of quality though. Change management is the key: how much is the project management cost of getting the site up-to-date in different languages. Does the CMS collect changes automatically, do I have to select individually what changes shall go to translation, do I have to ask for the quotation from the translator or issue a purchase order, do I have to convert the change-logs (i.e. the importable-exportable translation packages) manually into some format... if only two sentences change on a website and you synchronize everything real time, this all adds up into a much bigger cost than translation itself. Also, I know translators who would reject using a translation tool for two sentences unless there is some benefit they get (like a minimum fee if they return the TM too).
Without knowing the CMS in question it's hard to suggest the ideal file format. If you only synchronize changes once a month and this is a big site, and you'll have to manually convert XML into XLIFF, no prob. That's five minutes, and you'll pay several hundred euros for the translation. Small fraction. But if you need to convert every day, consider implementing a direct XLIFF export-import feature or use the existing XML export-import (if there's one) and create an XML format - more tools handle XML than XLIFF.
Sandeep, if you want to get meaningful information I think you should send more details about the CMS you use. This question in itself is almost as vague as asking whether it is useful to use clustered databases for a web service. We can give you some input, some aspects, but not answers.
Best regards,
István ▲ Collapse
| | | |
| Pages in topic: [1 2] > |
Login to reply/comment 
Translation news related to CAT tools
