-
Notifications
You must be signed in to change notification settings - Fork 16
English ruby terminology
Based on discussions among MURATA Makoto, Florian Rivoal, Elika Etemad, and Shimono Atsushi.
(2024-06) Discussions in progress here
If you are against to have some terms, leave these as comment for each one. If you have additional terms, add them at the bottom (into Additional terms)
The terminology in JLreq is chaotic. Let’s use better terms in simple ruby, text-to-speech requirements, the next version of JLreq, and CLreq! Ideally, our terms should be applicable to any document description language including HTML, CSS, OOXML, IDML, ODF, and so forth.
We intend to bring this list of terminology related to Ruby to official W3C document, such as W3C WG Note or a part of existing i18n-glossary, after having a consensus with other groups.
This document is written by group of terms, instead of each term, to make ease of understanding as explainer.
There are at least two ways to use this term. It may refer to ruby annotations. It may refer to pairs of ruby base and ruby annotation (e.g., the ruby element of HTML).
It is too late to choose one of them. We propose not to use this term for anything specific.
- kida: how about to leave the term as a name for the feature as a whole? For example the title of this document is "Ruby terminology". We need a term that describes the feature as a whole. [MM: Agree to use this term generically.]
Use ruby base and ruby annotation.
(These terms are generally used, not limited to Japanese.)
(formally written definition should be inserted here, with image?)
Ruby bases do not necessarily consist of text. Math expressions or images may be used as ruby bases.
We would propose not to use terms like base character or base text.
- (comments go here)
The JLreq TF agreed not to adopt any specific terms such as mono-style ruby, group-style ruby, and jukugo-style ruby.
- kida: The reason why we decided not to use these terms is to generalise ruby layout descriptions. These terms assume that the base text is a string of Kanji and the ruby annotation is a string of Kana. The distinction between the Mono- and the Group- is if the base text consists of more than one Kanji. The distinction between the Group- and the Jukugo- is if the ruby is segmented. The segmentation controls the layout and if they are line-foldable at the segment boundaries.
Use fully-annotated ruby markup and partially-annotated ruby markup (or ruby style) rather than general ruby and para ruby.
In the current JLreq terminology, general ruby and para ruby are defined and used.
para ruby came from the Japanese term パラルビ.
These concepts do not appear in the css-text specification, but are used in use case documents.
Note: In the JLreq TF, the origin of パラルビ was discussed. Kobayashi-san argued that パラ is not partial or parallel and that it came from パラパラ in Japanese. The other attendees agreed.
- JLreq TF is inclined to use 'sou-ruby' and 'para-ruby'.
- r12a: 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 (as they are already doing, with inline annotations rather than ruby), rather than multiplying 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.
Some terms are desired to describe pairs of ruby bases and ruby annotations (before or after line breaking?). Recall that ruby elements of HTML have both ruby bases and ruby annotations, also recall that a ruby element can have multiple base-annotation pairs. In the case of jukugo-ruby, line breaking may divide one base-annotation pair into two things.
No term is proposed in this terminology document, since different technologies handle such pairs differently.
- Kida: This term is necessary when we describe the layout for segmented ruby (i.e. like Jukugo-ruby). How about 'Segmented Ruby' and 'Ruby segments'?
Use interleaved ruby for base-annotation pairs in sequence, like 'rb rt rb rt rb rt' in HTML markup,
and layerd ruby for ruby bases followed by ruby annotations, like 'rb rb rb rt rt rt' in HTML markup.
- JLreq TF thinks that this term does not have to be defined in the I18N glossary. It may be defined in HTML or CSS Ruby.
- Kida: What are differences between these two? We would not need names if they are semantically equivalent.
- r12a: 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 in 2016. 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.