I am in total agreement with you. My view is that, like with the topic of inline elements, this is an attempt to impose on XLIFF a sub-optimal solution for a specific proprietary problem. This is exactly the kind of request that derailed XLIFF 1.2 and lead to the problems that we currently have. XLIFF should be kept as simple as possible.
If you want to present various language translations then the answer is that you should aggregate multiple language XLIFF files in your application and not impose an unnecessary burden on XLIFF.
Best Regards,
Andrzej Zydroń
CTO
XTM International
Tel: +44 (0) 1753 480 469
Fax: +44 (0) 1753 480 465
Mob: +44 (0) 7966 477 181
email: azydron@xtm-intl.com
www: http://www.xtm-intl.com
Skype: zydron
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you may not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission. If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.
On 18/01/2012 07:48, Yves Savourel wrote:
Hi Stephan, all,Bryan gives a pertinent use case here. Since I was not able to follow the discussion from the beginning, this question may be redundant: * What is the rationale to not extend the standard to multilingual contents? I believe that nicely aligned multi lingual xliffs are beneficial for revision and proofreading tasks.Personally I think an XLIFF document should address only a bilingual case because that is the smallest unit we have to deal with. For example getting a multilingual XLIFF from a CMS system would force a lot of processing before we (i.e. an LSP) could dispatch it to the proper translators. And same thing in its way back. I think multilingual packages are perfectly fine, but they should be represented at the package level, in other words at a higher level than XLIFF.It can also be helpful for consistency when e.g. an Italian translator gets in his xliff previously translated and approved Spanish texts.Having the user doing the Italian translation see the approved translation of the Spanish would need a major adjustment of the XLIFF tools to treat different translations as hints. Another way would be to have such translation hints provided using <alt-trans> and that is supported. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org