[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-translation] Re: [dita] Proposal: Domain for Japanese ruby markup ala HTML5
JoAnn, thanks for forwarding Tetsuya-san's e-mail to the list. His support for a Ruby domain for DITA 1.3, especially in regard to its need for mobile applications and ePubs, matches the discussion that we had on the TC call this week. Best regards, Kris Kristen James Eberlein | DITA Architect and Technical Specialist | SDL Structured Content Technologies Division | (t) + 1 (919) 682-2290| keberlein@sdl.com Santa Clara | March 5-6 www.sdl.com/innovate Kris -----Original Message----- From: dita-translation@lists.oasis-open.org [mailto:dita-translation@lists.oasis-open.org] On Behalf Of JoAnn Hackos Sent: Friday, February 03, 2012 11:01 AM To: Eliot Kimber; Rodolfo Raya; DITA TC Cc: dita-translation@lists.oasis-open.org Subject: [dita-translation] Re: [dita] Proposal: Domain for Japanese ruby markup ala HTML5 Hi, I thinking Eliot, you may be stretching the circumstances and overstating the case. Technical communications documents have been happily produced from DITA into Japanese for years with no need for Ruby. Ruby is not essential for Japanese documents at least with PDF etc. publications. My understanding from Translation SC discussions before 1.2 is that Ruby is chiefly used in schoolbooks. Now we have the note from Tetsuya Sekine that mentions several important issues, possibly connected with ebooks. I've copied his note here for those who did not see it. I think it's really important that we not overstate or misrepresent the case. I invite all members of the DITA Translation Subcommittee to comment in this thread. Thanks, JoAnn JoAnn T. Hackos, PhD President Comtech Services Inc. 710 Kipling Street, Suite 400 Denver, CO 80215 Joann.hackos@comtech-serv.com 303-232-7586 Hi all, I was already discussed some of you, regarding Ruby functionality. Only problem is that meeting is held during the time, I am not usually be able to attend. I discussed this issue with some colleagues in the field. 1.Currently, most of the users and information developers are not necessary needing Ruby. WHY: Because in Technical Communication, this does not have much impact on current targeted audiences (Paper, PDF, Online Help) HOWEVER: From the point of accessibility and computer-voiced instructions feature especialy to the new deliverables such as smartphone, Ruby will be needed. 2.Rendition part is already supported by tools like AH XSL Formatter, and the same things applied with current HTML browser and its standard (HTML5/CSS3). 3.DITA adaption for the commercial publishing definitely needs Ruby, so this can contribute DITA to be adapted more in that field, in conjunction with ePub. 4.It is not a good way to extend Ruby as the Japanese own specialized implementation because this action is against open standard. (From my own experiences, Japanese have a tendency to come up with own domestic standard and make things complicated, not align with the standard) PS In addition to Ruby, we want to have the similar elements as used in <indexterm>/<index-sort-as> for glossary entries, in order to sort from "yomigana" One of our customers decided to specialize in order to have sorting in glossary As said enough, I am for the Eliot, Nancy's proposal for standardization in DITA data model, align with HTML5 and ePub etc. Tetsuya Sekine ====================================================================== Tetsuya Sekine President, Principal Consultant InfoParse, Inc. <your one stop DITA contact/> <DITA + /> *email: ecmp@infoparse.com | Skype <callto://tetsekine> *url: www.infoparse.com | phone: 81 3-3736-8180 On 2/2/12 3:42 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote: >The rational as I provided it to the TC during meeting was: > >1. Ruby markup is essential for the publication of Japanese-language >documents (and for some other ideographic languages). > >2. Japan is rapidly adopting DITA > >3. Many DITA users localize their documents to Japanese > >4. Without a ruby solution, Japanese users either cannot use DITA or will >be >forced to invent their own individual specializations. > >Nancy Harrison echoed the fact that ruby markup is essential for Japanese >documents. > >5. The ruby markup is well-defined in HTML and needs no refinement from >us. >Therefore, the standardization cost to the TC is very low (and in fact >I've >already done everything except write the language reference topics since I >originally implemented this in DITA for Publishers). > >6. The rendition implementation is trivial for HTML outputs and available >for PDF outputs (i.e., Antenna House have developed particular XSL-FO >patterns for rendering ruby annotations). > >Note that in my proposal the ruby markup is packaged as a separate domain >and would presumably not be integrated into the generic document type >shells >provided by the TC and so would not add to the set of elements seen by >default for typical DITA users using default document types. > >Cheers, > >E. > >On 2/2/12 4:33 PM, "JoAnn Hackos" <joann.hackos@comtech-serv.com> wrote: > >> Hi, >> Eliot, could you put together a rationale for adding Ruby support that >>we >> can present to the Translation SC? I have your original email to the >>DITA >> TC but what I need is why this is valuable for the entire DITA >>community. >> The SC didn't think that was true when we were reviewing DITA 1.2 >> proposals. >> >> Thanks, >> JoAnn >> >> JoAnn T. Hackos, PhD >> President >> Comtech Services Inc. >> 710 Kipling Street, Suite 400 >> Denver, CO 80215 >> Joann.hackos@comtech-serv.com >> 303-232-7586 >> >> >> >> >> >> >> >> On 2/1/12 3:06 PM, "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote: >> >>> Hi, >>> >>> It would be indeed interesting to pass the new proposal to the >>>Translation >>> SC for analysis. >>> >>> Is there anything really different in the new proposal for adding Ruby >>> support? What has changed that could make the Translation SC change its >>> opinion? >>> >>> Regards, >>> Rodolfo >>> -- >>> Rodolfo M. Raya rmraya@maxprograms.com >>> Maxprograms http://www.maxprograms.com >>> >>> >>>> -----Original Message----- >>>> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On >>> Behalf >>>> Of JoAnn Hackos >>>> Sent: Tuesday, January 31, 2012 10:14 PM >>>> To: Eliot Kimber; Richard Hamilton >>>> Cc: DITA TC >>>> Subject: Re: [dita] Proposal: Domain for Japanese ruby markup ala >>>>HTML5 >>>> >>>> I think this proposal needs to be discussed by the Translation SC. >>>>Let's >>> see if >>>> we can reconvene it. We considered Ruby markup for DITA 1.2 and >>>>decided >>>> against recommending it. I don't know if the members of the SC think >>>> differently today. >>>> >>>> JoAnn >>>> >>>> JoAnn T. Hackos, PhD >>>> President >>>> Comtech Services Inc. >>>> 710 Kipling Street, Suite 400 >>>> Denver, CO 80215 >>>> Joann.hackos@comtech-serv.com >>>> 303-232-7586 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 1/25/12 10:21 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote: >>>> >>>>> Good point--the markup is primarily driven by Japanese requirements >>>>>but >>>>> it is not unique to Japanese typography as you say. >>>>> >>>>> Cheers, >>>>> >>>>> E. >>>>> >>>>> On 1/25/12 11:18 PM, "Richard Hamilton" <hamilton@xmlpress.net> >>>>>wrote: >>>>> >>>>>> Eliot, >>>>>> >>>>>> I agree that it probably should be a domain, for the reasons you >>>>>> describe. >>>>>> However, there are other languages where a phonetic "ruby" could be >>>>>> useful. >>>>>> I've seen the same kind of thing in Chinese texts (mostly in >>>>>>language >>>>>> learning aids), and I'm sure there are other uses. >>>>>> >>>>>> So, I would suggest that any specification description not imply >>>>>>that >>>>>> usage is limited to Japanese. >>>>>> >>>>>> Best Regards, >>>>>> Richard >>>>>> ------- >>>>>> XML Press >>>>>> New from XML Press: >>>>>> WIKI: Grow Your Own for Fun and Profit >>>>>> http://xmlpress.net/publications/wiki-how-to-grow >>>>>> >>>>>> On Jan 25, 2012, at 8:56 PM, Eliot Kimber wrote: >>>>>> >>>>>>> HTML5 provides an improved version of HTML 4's <ruby> markup, which >>>>>>> is required for Japanese-language documents that include kanji >>>>>>> (ideographic) >>>>>>> characters. >>>>>>> >>>>>>> In Japanese, the pronunciation of ideographic characters cannot >>>>>>> always (or >>>>>>> often) be known from context. The ideographic characters are >>>>>>> annotated with their phonetic transliteration, a "ruby", which is >>>>>>> rendered above or beside or following the ideographs. This is >>>>>>> standard Japanese typography. >>>>>>> >>>>>>> In the context of the DITA for Publishers vocabulary I have defined >>>>>>> a direct copy of the HTML5 markup design, e.g.: >>>>>>> >>>>>>> <p> 探険船シビリアコフ号の北氷洋航海中に撮影されたエピソ >>>> ード映画の中に、一頭 >>>>>>> の<ruby> >>>>>>> <rb>白熊</rb> >>>>>>> <rp>（</rp> >>>>>>> <rt>しろくま</rt> >>>>>>> <rp>）</rp> >>>>>>> </ruby>を射殺し、その子を生け捕る光景が記録されている。 >>>> </p> >>>>>>> >>>>>>> Implementing this for HTML output is trivial--just copy to output. >>>>>>> For PDF it's a little more work but can be done in XSL-FO. >>>>>>> >>>>>>> <ruby> and its ruby-specific subelements are specializations of >>>> <ph>. >>>>>>> >>>>>>> I am proposing this as a new domain simply to keep the vocabulary >>>>>>> isolated so that non-Japanese-language documents need not include >>>>>>> this markup. >>>>>>> But it >>>>>>> would equally appropriate to add it to the DITA base vocabulary as >>>>>>> well. >>>>>>> >>>>>>> The Ruby markup works as expected in most modern browsers and in at >>>>>>> least iBooks for EPUB. I have not tested on Kindle Fire. >>>>>>> >>>>>>> The HTML5 specification for <ruby> is here: >>>>>>> >>>>>>> http://dev.w3.org/html5/spec/Overview.html#the-ruby-element >>>>>>> >>>>>>> The D4P vocabulary module and HTML implementation for the Open >>>>>>> Toolkit is available as part of the DITA for Publishers package, >>>>>>> dita4publishers.sourceforge.net. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Eliot >>>>>>> >>>>>>> -- >>>>>>> Eliot Kimber >>>>>>> Senior Solutions Architect >>>>>>> "Bringing Strategy, Content, and Technology Together" >>>>>>> Main: 512.554.9368 >>>>>>> www.reallysi.com >>>>>>> www.rsuitecms.com >>>>>>> >>>>>>> >>>>>>> >>>>>>>-------------------------------------------------------------------- >>>>>>> - To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>>>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Eliot Kimber >>>>> Senior Solutions Architect >>>>> "Bringing Strategy, Content, and Technology Together" >>>>> Main: 512.554.9368 >>>>> www.reallysi.com >>>>> www.rsuitecms.com >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>> >> > >-- >Eliot Kimber >Senior Solutions Architect >"Bringing Strategy, Content, and Technology Together" >Main: 512.554.9368 >www.reallysi.com >www.rsuitecms.com > --------------------------------------------------------------------- To unsubscribe, e-mail: dita-translation-unsubscribe@lists.oasis-open.org For additional commands, e-mail: dita-translation-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]