Re: [dita-translation] More on ruby

[Andrzej Zydron <azydron@xml-intl.com>]

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.