Capture comments from closed ARIA issue into the ruby-t2s-req Note

[cookiecrook]

I made some suggestions in https://github.com/w3c/aria/issues/1620#issuecomment-954501658 and surrounding comments, that I don't think are fully captured in https://w3c.github.io/ruby-t2s-req/

In particular, I don't see a related Ruby issue about the potential need for new type values, or some other native feature that solves the same problem. Though maybe I missed it.

A similar issue was raised recently in another context, that I interpret as being the same, or very similar to the need called out in https://github.com/w3c/aria/issues/1620#issuecomment-954501658

Although I can't take on a Pull Request immediately, if you'll add me to the project and assign this issue to me, I'll add it to my backlog assignments. Looking again, we may need something in the Ruby spec (such as the suggested new type values), or a new Ruby-AAM document that could include expectations for role, label, and other mappings.

Quoting here but refer to the cross-referenced issues for replies:

This following comment does not represent a consensus view of any organization (WG, employer, etc). It's just a collection of ideas that may be helpful in your progress to find a workable solution.

You mentioned three functional distinctions in your use cases, but I see several more semantic content types in the User Requirements page. I'll attempt to outline them here, including similar examples in English. Note that category 2 (phonetic-optional) incorporates both a speech use case, as well as the mainstream use case you mentioned today. To allow the user to toggle the visible display of these optional groupings.

The bolded names categories are just suggestions to help me keep them straight. I'm not particular to the names.

1. phonetic-required: Phonetic usage where the rt should always be visibly displayed and pronounced, as it defines an uncommon pronunciation that most would not know.

   • your unusual people and place names example
   • As a similar place example from the US, there is a road in Austin spelled both "Manchaca" and "Menchaca" but is pronounced by most locals as "Man-Chack."
   • possibly your Dewanai example, which as I understood it, is equivalent to the English "My name is Knot not" which means "My name is Knot" but may be misspoken by TTS (and misunderstood) as "My name is not Knot."

2. phonetic-optional: Phonetic usage where the rt provides a pronunciation hint to less-experienced readers. Toggling the visible display of these may be be context dependent, as experienced readers would not need them and may find them distracting. Text-to-speech may(?) pronounce the base text as it is sometimes less ambiguous than the rt, but in most cases, the TTS pronunciation of the rt or base will be identical.

   • Beginning to intermediate readers, such as your furigana examples
   • Difficult-to-pronounce Species or Pharmaceutical names may be appropriate to include here, such as oxoerythromycinoxo-eur-ithro-mycin or oxoerythromycin/ɒk.sə(ʊ).ɪˌɹɪθ.ɹə(ʊ)ˈmʌɪ.sɪn/. Some readers may find the pronunciations helpful, where a domain expert may prefer to hide the pronunciation.

3. phonetic-complementary Phonetic usage where the both the rt and the base should be spoken.

   • Some of your Gikun examples such as 背景 バック (HAIKEI back). These are a type of phonetic usage, but in this context, the phonetic rt kana does not define the pronunciation of the base, so the text-to-speech user would miss out on some context if only one were spoken.

4. notes Interlinear notes, a non-phonetic usage where the both the rt and the base should be spoken. Similar usage to a parenthetical in western languages.

   • 徳川家康1543-1616 江戸幕府最後の将軍, effectively "Tokugawa Ieyasu (1543-1616, the last shogun of the Edo shogunate)"

5. wordplay? another non-phonetic usage where the both the rt and the base should be spoken. (I'm not certain "wordplay" describes all similar uses)

   • Your example of enemyfriend meaning frenemy (I could not copy the Japanese text out of your images)
   • Another example from a colleague: 丁度良い所に常連カモが来たよ (look, here comes a regular customer now) where 常連 (regular customer)’s ruby says カモ (easy target/victim)

The semantic categories 3, 4, and 5 equate to the same functional category: "always display and speak both" so they might be combined (parenthetical??) if there's no other functional need to keep them separate.

What about proposing a new type attribute on the <ruby> element with values [phonetic-required | phonetic-optional | parenthetical ]?

Once the Ruby/HTML working group agrees on a specific attribute, we could map it to accessibility and speech APIs to achieve the correct pronunciations, and use it for the other education use case of a visibility toggle on optional Ruby.

[Update: after discussion, replaced the initial "complementary" value proposal with "parenthetical"]

[cookiecrook]

Of note, it looks to me like the https://github.com/w3c/i18n-activity/issues/1433 issue was closed before getting a new feature proposal in Ruby, as recommended by the ARIA WG review.

[murata2makoto]

@cookiecrook Thank you for the heads up and kind offer. I am painfully aware that I have been very lazy about this project. Three guys recently pinged me.

I will add you to the project and assign this issue to you. I will have a careful look tomorrow or the day after tomorrow.

[murata2makoto]

@himorin Could you add James to this project? Thanks!

[cookiecrook]

FYI @frivoal re: https://w3c.github.io/jlreq/docs/simple-ruby/

possibly some overlap in the simple-ruby requirements for

ruby-less display, general-ruby display, and para-ruby display

…and the bikeshed ruby-t2s-reqs ideas discussed at https://github.com/w3c/aria/issues/1620#issuecomment-954501658 for type values such as:

phonetic-required, phonetic-optional, parenthetical/notes, etc.

[murata2makoto]

@cookiecrook JLTF decided to discontinue the development of simple-ruby. Its content will be moved to the upcoming V2 of JLreq. The technical content of simple-ruby is still useful, but the terminology will be different.

[cookiecrook]

Sharing some additional examples gathered by colleagues.

Ruby Types	Use Cases	Example
Mono-ruby	defined to have a single character as its ruby base. When the ruby base of one ruby block has multiple characters, it is either Group-ruby and Jukugo-ruby. When the ruby base is segmented into each character, and a ruby annotation is attached to each, then it is a Jukugo-ruby. When a ruby annotation is attached to the whole ruby base, then it is a Group-ruby.
Group-ruby	used when ruby is attached to a group of base characters together.
Jukugo-ruby	used when each character of the base text have a corresponding ruby annotation and at the same time the whole group needs to be processed together
special kanji readings熟字訓	A Japanese word written with two or more kanji characters because the readings are unrelated and the meanings are similar.漢字の読みには関係なく，意味が似ていることなどから，1つの和語を2字以上の漢字で表記したもの。	「滅茶苦茶」（めちゃくちゃ = Mecha Kucha）、「 昨日 (きのう= Kinou )」「 大人 (おとな =Otona) 」「 五月雨 (さみだれ=Samidare) 」「紫陽花」（あじさい=Ajisai)
phonetic-equivalent character当て字	a word that is applied by borrowing the sound or pronunciation of a kanji, regardless of its meaning.漢字の意味に関係なく、音や訓を借りて当てた言葉	- Write「女(Onna)」and pronounce as「ひと(Hito)」- Write「運命(Unmei)」and pronounce as「さだめ(Sadame)」- Write「倫敦」pronounce as（ロンドン=London）, 珈琲（コーヒー=Coffee）秋桜（コスモス=Kosumosu）出汁（だし=Dashi）

[cookiecrook]

Looking forward to getting back to this Ruby proposal. One more potential type not previously mentioned here is pictorial, symbolic, or similar, such as would be used for Bliss Symbolics or ARASAAC. See related topic in https://github.com/w3c/adapt/issues/240

[murata2makoto]

I am painfully aware that I am so guilty! I will speak with JLTF people tonight and respond tomorrow.

[cookiecrook]

Please do not feel guilty. I am assigned and have not been able to prioritize this one yet either. Thank you!

[murata2makoto]

Re: Mono-ruby/Group-ruby/Jukugo-ruby

W3C JLTF is preparing the next version of JLreq. JLTF decided to drop these terms in that version. More about this, see https://github.com/w3c/jlreq/wiki/English-ruby-terminology

Moreover, mono-ruby, group-ruby, and jukugo-ruby relate to the visual layout of ruby. I do not think that they have to be mentioned in this document.

[murata2makoto]

I do not think that special kanji readings熟字訓 has to be mentioned in this document. As long as TTS is concerned, it is just Furigana. Gikun has to be mentioned since different ruby annotations are attached depending on the context. Meanwhile, in the case of special kanji readings熟字訓, the same ruby annotation is always used.