[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-translation] More on ruby
Hi Gershon, According to the W3C Localization tutorial (http://www.w3.org/International/tutorials/ruby/) "Typically ruby is used in East Asian scripts to provide phonetic transcriptions of obscure characters, or characters that the reader is not expected to be familiar with. For example it is widely used in education materials and children’s texts. It is also occasionally used to convey information about the meaning of ideographic characters." Ruby is only relevant to DITA if it is felt that there is a requirement for it in East Asian languages. Ruby is not compulsory for publishing Japanese or other East Asian text, it merely allows the author/translator to provide some indication regarding pronunciation which would otherwise not be obvious (something we would do using a phonetical rendition in parentheses) e.g. Zydroń (pron. Ziddrogne). I have personally been involved with publishing technical documentation into Japanese for over 15 years and have yet to come across a situation where the lack of Ruby support has been a problem. Therefore, IMHO, Ruby is not a pressing need regarding DITA 1.1. It is worth considering it, with regard to providing enhanced support for East Asian scripts in DITA 1.2. Best Regards, AZ Gershon L Joseph wrote: > Hi all, > > Following up to our discussions at last Monday's Translation subcommittee > discussions about Ruby: > > - Discuss a possible proposal for inclusion of the ruby > attribute/element in the DITA specification > - Don proposes not to include ruby for DITA in source, but to > discuss best practice to ensure annotation capability is > provided for in DITA and it could be interpreted into > ruby-like markup (i.e. keyref). > - JoAnn - investigate a little further, but not applicable to > 1,1, and we may have an alternative in the keyref. Add > recommendation for processors on how keyref may be > interpreted to ruby > -- ACTION ITEM -- Gershon to research more and discuss with > Richard for decision next meeting. > > After a little more thinking, I feel we should accept JoAnn's move to remove > Ruby from DITA 1.1. After 1.1 (or maybe even after 1.2), we could > investigate whether the keyref attribute could be used to hold Ruby data > that would be output to the appropriate Ruby markup at publishing time. > Personally, I think we should wait for users to request Ruby support before > we consider any further work (documenting best practices, changing the spec, > or anything else) related to Ruby. I feel our efforts should rather be spent > on 1.1 items at this time. > > Best Regards, > Gershon > > --- > Gershon L Joseph > Member, OASIS DITA and DocBook Technical Committees > Director of Technology and Single Sourcing > Tech-Tav Documentation Ltd. > office: +972-8-974-1569 > mobile: +972-57-314-1170 > http://www.tech-tav.com > > > > --------------------------------------------------------------------------------------------------- > Text inserted by Panda Platinum 2005 Internet Security: > > This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: http://127.0.0.1:6083/Panda?ID=pav_47689&SPAM=true > --------------------------------------------------------------------------------------------------- > > -- email - azydron@xml-intl.com smail - c/o Mr. A.Zydron PO Box 2167 Gerrards Cross Bucks SL9 8XF United Kingdom Mobile +(44) 7966 477 181 FAX +(44) 1753 480 465 www - http://www.xml-intl.com 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]