-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
todo: Update Ruby terminology wiki and solicit feedback from clreq #385
Comments
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."? |
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...) |
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.
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. |
Murata-san asked about the terms for 総ルビ and パラルビ by email, posting my response here on his request:
|
Murata-san asked me about interleaved vs tabular ruby by email, posting my response here on his request (part of which r12a quotes above):
|
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. |
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. |
@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. |
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. |
The next version of JLreq should certainly be written without using "general ruby" and "para ruby". |
todo for @murata2makoto, from JLReq TF meeting on 2023-10-31.
Below is from meeting notes:
The text was updated successfully, but these errors were encountered: