OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Product names and reuse


Title: Email signature standard
Hi Andrzej:

We translated the English XML content and mapping files into multiple languages, including Chinese, Japanese, and Arabic, which are probably some of the more difficult languages to translate. The agencies worked with our build kit and generated translated versions per language, including PDF. Granted, we had some great development resources to program the XSLT and XSL:FO appropriately to handle multiple languages.

I do remember some iterations where translation had to tweak the PDF output until we programmed a solution (indexing was challenging for Japanese, right-to-left languages, etc.). In any case, the amount of total manual work translation had to perform versus previous iterations was massively reduced with subsequent cost savings and rapid turn-around. From what I recall, we reached 100% automation for all languages handled.

If you could be more specific about which language morphologies cannot work with variables, I'd be interested. In some cases, the best solution might be to dump out an XLIFF with resolved values for variables, so the base XML isn't translated, but the XLIFF version of the same with a two-way transformation back to the build kit for a translated version of deliverables.

Some translation groups will work with build kits, some don't, so this also needs to be factored into workflow.

So I suspect that there may be no perfect global solution to handle all possible languages from base DITA XML, but a technical solution that handles most and then an alternate workflow for those languages that cannot work with variables as such.

Troy

On 1/15/2013 1:34 PM, Andrzej Zydron wrote:
Hi Troy,

Thank you for this interesting post. Your mechanism will work for English, and the small group of languages with a similar primitive morphology. Unfortunately it will fall apart when you come to translate the XML content into any language with a richer morphology - the resultant output will produce ungrammatical output and the cost of recovery from this will be extensive.

English is a linguistic freak (
a fact that is lost on most monolingual English speakers) which allows for the relative easy substitutions that you described. I you plan to translate your content into other languages this is not a practical possibility.

Best Regards,


Andrzej Zydroń

---------------------------------------

CTO

XTM International Ltd.

PO Box 2167, Gerrards Cross, SL9 8XF, UK

email: azydron@xtm-intl.com              

Tel: +44 (0) 1753 480 479

Mob: +44 (0) 7966 477 181

skype: Zydron

www.xtm-intl.com

 

Description: Description:
                  cid:image002.png@01CCE7FF.2711B390

 

 

 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]