todo: Update Ruby terminology wiki and solicit feedback from clreq

[kidayasuo]

todo for @murata2makoto, from JLReq TF meeting on 2023-10-31.

• Update Ruby terminology wiki based on the discussions at the meeting
• Clarify if there are semantic difference between “rb/rb/rt/rt”and “rb/rt/rb/rt”
• Solicit feedback from clreq folks.

Below is from meeting notes:

• data: a presentation and a wiki
• We have decided not to use Mono, Group and Jukugo Ruby in ruby layout descriptions in jlreq-d because these terms have an assumption that the base text is a string of Kanji and the ruby annotation is a string of Kana. We want to generalise the ruby layout in jlreq-d so it does not have assumptions on the script used for the base or the ruby annotation. These terms will be touched on in side notes.
• Remaining issue regarding the terminology is if we define a name for the combination of the base text and ruby annotation. Kida: When I drafted a proposal of line-foldable ruby I often felt the need for the term. Bin-sensei: the term ‘Oyamoji-gun (base text group)’ was used in JIS X 4051. - no conclusion
• Murata: related to the topic do we need a term for “rb/rb/rt/rt”and “rb/rt/rb/rt” ? I do not know if they are differ in the resulting layout. todo: need to clarify.
• Murata: When we say “ruby” what does it mean? It was sometimes used to describe the annotation attached, and sometimes it means the feature as a whole. The annotation part should be called “ruby annotation” for clarify.
• For para-ruby and sou-ruby, JLReq TF folks thinks they can be used as-is.

[r12a]

I left some comments at https://github.com/w3c/jlreq/wiki/English-ruby-terminology, but after reading recent emails it seems i should add them here also.

@kidayasuo perhaps we should tweak "Please leave your comments directly into comments section as itemized list, with your name. No issue (nor PR) is required for leaving comment."?

[r12a]

For para-ruby and sou-ruby, JLReq TF folks thinks they can be used as-is.

The term 'para-ruby' was always a problem for me because it's not at all obvious what it refers to. It was necessary to define it before using it anywhere. Introducing 'sou-ruby' alongside that seems to be doubling the problem.

In addition, these are Japanese terms, and chinese people should be able to use less japanese-sounding terms. Same, of course, goes for Korean and Mongolian.

The clreq folks are already using the term 'inline annotations' rather than 'ruby', which increases the number of terms referring to the same thing. Same, of course, goes for Korean and Mongolian.

Fully-annotated & partially-annotated ruby markup are a little long, but they are terms that clearly describe what is being referred to, so i like that.

Initially, i thought that @fantasai 's suggestion of fully-annotated text sounded interesting, but actually i don't think it's specific enough. There are other types of text annotation, such as wakiten, and i expect it will be useful to have the more specific 'fully-annotated ruby markup'. (Fully-rubified text might work if it sounded less naf and more like real English...)

[r12a]

Murata: related to the topic do we need a term for “rb/rb/rt/rt”and “rb/rt/rb/rt” ? I do not know if they are differ in the resulting layout. todo: need to clarify.

Although semantically both approaches can be used for the same thing, @fantasai's email mentions some useful points about the implications for handling ruby of both types. I'll repeat those points here to perhaps save @fantasai some time, hoping that i don't misconstrue anything.

When you use the (rb, rt)+ pattern:

• the fallback behavior is not good (per-syllable fallback, rather than per-word)
• naive screenreading is terrible (per-syllable repetition, rather than per-word)
• intentional inline rendering of ruby would require new complicated capabilities in CSS to render it as per-word. (Technically it can be done as a new feature that moves text inside a SPAN or something like that, but... proper inline rendering can be done right now with display: inline when the (rb, rt)+ pattern is used.)

As for naming the two approaches, here's the comment i left in the wiki:

I had to come up with terms to describe these two approaches many years back, and settled on Interleaved Ruby and Tabular Ruby - see https://www.w3.org/International/articles/ruby/markup.en.html#tags where i used these terms back in 2016, and described the differences. In https://www.w3.org/International/articles/ruby/markup.en.html#tabular i explain the rationale for using 'tabular' (see just below the grey box). I'd like to recommend that we continue using 'tabular ruby' so that i don't have to find and rewrite all the existing material referring to this, and so that we don't multiply the number of terms in existence that are referring to the same thing.

[fantasai]

Murata-san asked about the terms for 総ルビ and パラルビ by email, posting my response here on his request:

[sou-ruby and para-ruby] is workable, but maybe a bit awkward. :) But I can see that "fully-annotated ruby" and "partially-annotated ruby" is also a bit awkward.

One possibility might be:

• partial ruby (パラルビ)
• full|complete ruby (総ルビ)

Another possibility is, well, you're not so much talking about the ruby being fully/partially-annotated as the base text being fully/partially-annotated, so what about

• fully-annotated text
• partially-annotated text

?

Incidentally, I would probably use the word "practice" rather than "method" in this section: https://w3c.github.io/jlreq/#choice_of_base_characters_to_be_annotated_by_ruby I'm having trouble articulating why, though...

[fantasai]

Murata-san asked me about interleaved vs tabular ruby by email, posting my response here on his request (part of which r12a quotes above):

Are there any fundamental differences between rb+ rt+ and (rb, rt)+ ? For example, is some layout impossible for the former?

Nothing is impossible, exactly, but when you use the (rb, rt)+ pattern:

• the fallback behavior is not good (per-syllable fallback, rather than per-word)
• naive screenreading is terrible (per-syllable repetition, rather than per-word)
• intentional inline rendering of ruby would require new complicated capabilities in CSS to render it as per-word. (Technically it can be done as a new feature that moves text inside a SPAN or something like that, but... proper inline rendering can already be done right now with display: inline when the (rb, rt)+ pattern is used.)

Note that (rb, rt)+ is already implemented in Firefox and Kindle, and it seems likely for it to be added to WebKit and Blink in the near future also. (Blink already sent an Intent to Implement.)

I think Florian did a talk about this: I have this link from him, but my Japanese is not advanced enough to know what exactly he is explaining. ^_^ https://www.youtube.com/watch?v=S4xE8hCOmK8&t=2198s

[frivoal]

For para-ruby, I remember being confused because I thought it meant parallel-ruby, and I didn't understand what parallel could mean in this context. I think the suggestions from fantasai are likely more easily understood.

[kidayasuo]

@kidayasuo perhaps we should tweak "Please leave your comments directly into comments section as itemized list, with your name. No issue (nor PR) is required for leaving comment."?

Could you elaborate? @murata2makoto manages the page.

I have a question. Are there places where the term sou/para-ruby or other terms of the same concept is used other than within JLReq (and parhaps jlreq-d)? I am curious because they do not affect how rubies are laid out; they are about how authors use rubies.

[murata2makoto]

I left some comments at https://github.com/w3c/jlreq/wiki/English-ruby-terminology, but after reading recent emails it seems i should add them here also.

@kidayasuo perhaps we should tweak "Please leave your comments directly into comments section as itemized list, with your name. No issue (nor PR) is required for leaving comment."?

@himorin and I thought that JP experts are not necessarily used to GitHub issues, and hoped that the wiki is easier. But people did not use the wiki very well. Recently, JP experts (most notably Kobayashi-sensei) started to use GitHub issues. So, I am inclined to rely on GitHub issues. In the F2F meeting today, we will discuss how to use GitHub issues.

[murata2makoto]

The JLreq TF finds that terms for sou-ruby/para-ruby are not used anywhere. In our understanding, neither HTML nor CSS need such terms. (Correct us if we are wrong.)

The only exception is Schema.org Accessibility Properties for Discoverability Vocabulary . It does distinguish publications containing sou-ruby and those containing para-ruby. But for this purpose, I introduced two values (fullRubyAnnotations and rubyAnnotations) and described their semantics in prose without using sou-ruby/para-ruby. Thus, there are no reasons to standardize terms for sou-ruby and para-ruby.

[murata2makoto]

The next version of JLreq should certainly be written without using "general ruby" and "para ruby".