Re: Discontinuing simple-ruby

Hi,

I partially support the proposal, but with some nuance.

I am in favor of wrapping up any pending edit, publishing, and stopping 
the work there. I do not believe that this documents needs long term 
maintenance, so including a statement in the Status of this Document 
that this document is published as is and that there are no plans for 
ongoing maintenance seems reasonable.

(To be honest, I never expected that so much work would go into 
editorial refinements after the first publication. I'm glad they 
happened as there was certainly much room to improve over my initial 
translation, but that exceeds my initial expectation, which was more of 
a one-shot publication.)

I do not think, however, that it is useful to mark it as "discontinued", 
"obsolete", "superseded", or any other pejorative qualifier that would 
indicate that it is no longer relevant or appropriate to read.

In my mind, the fact that it's scope is narrower than full modern usage 
of ruby, particularly on the web, is not a bug, it is a feature. I don't 
think this document ever tried to be a grand theory of how to do ruby 
layout in a generic way. It would indeed fall awfully short of that goal 
if that's what it attempted.

I believe it serves a different purpose: skip the complexities 
introduced by all the corner cases of generalized ruby, and showcase 
what a reasonably nice ruby layout looks like in typical situations, 
while keeping it simple. This document is educational much more than 
specification-like.

Why is that useful? The CSS Ruby Annotation Layout Module Level 1 is 
much more generic, much more robust, and handles many more variants and 
many more situations than Simple Ruby. However, it also has a fair few 
areas which are deliberately "undefined" or "up to the user agent". And 
these are not only about corner cases, but also about areas where we 
expect that implementations may want to differ and vary in quality.

Most implementers of browser engines are not Japanese. Most do no have 
deep knowledge of the ruby typography tradition, nor a strong sense of 
what good ruby, simplistic ruby, or bad ruby looks like. Some may, but 
not all.

If an implementer reaches one of these parts of the spec that tells them 
that in a particular area they're free to do whatever feels best to 
them, where should they find guidance? JLREQ describes a variety of 
options, but refrains from judging them, so it only partially help.

I think this is a case where Simple Ruby helps. It does not give you the 
best way to do ruby. It doesn't even give you a complete way to do ruby. 
It skips over too many details, and too any interactions with other 
parts of layout. But it does give you "if you do something that works 
like this in typical situations, that's considered pretty good.".

Finally, about the "mono-ruby", "group-ruby", or "jukugo-ruby" 
terminology, I'd be inclined to think that despite their imperfections, 
they are useful terms because they have been widely over a long period 
of time, and keeping terminology consistant can be helpful for readers 
learning about this subject matter. I don't have an objection to future 
documents coming up with better terminology, but neither do I think that 
any document that uses the traditional terms is automatically bad or in 
need of rewriting.

—Florian



On 2024/03/09 23:28, 木田泰夫 wrote:
> Dear I18N WG,
> 
> The JLReq Task Force would like to discontinue the development of the 
> simple-ruby document (https://www.w3.org/TR/simple-ruby/ <https:// 
> www.w3.org/TR/simple-ruby/>, https://github.com/w3c/simple-ruby 
> <https://github.com/w3c/simple-ruby>). I notified the intention to some 
> of you in June, 2023. I would like to make it official.
> 
> *Background*
> Briefly speaking we are discontinuing the document as we are planning a 
> fundamental overhaul of the current description of ruby in jlreq-d which 
> is in development. For example:
> 
> - We decided to stop using terms such as mono-ruby and group-ruby which 
> reflects traditional workflow but do not necessarily aligned with modern 
> architecture such as CSS. As mono- and group- rubies are very similar, 
> unifying the two makes the description straightforward. Jukugo-ruby can 
> be explained as a segmented ruby in a more generic way. Old terms will 
> be described as historical concepts in side notes.
> 
> - Current description includes implicit assumptions that the base text 
> and ruby are in fullwidth characters, and that the base is in Kanji and 
> the ruby is in Kana. Considering modern usage of ruby with Japanese text 
> it needs to be more generic, with explicit special casing for such a 
> typical case where necessary.
> 
> *Plan*
> We would like to update the document with currently open pull requests, 
> publish it and make it a discontinued document. Open issues will not be 
> addressed in simple-ruby but we will review them and move ones that are 
> still relevant to jlreq-d.
> 
> 
> Please let me know if you have any questions.
> 
> Thank you!
> 
> Best REgards,
> 
> - kida

—Florian

Received on Sunday, 10 March 2024 05:26:07 UTC