Identical section titles reduce understandability

[cookiecrook]

Re: understandability, there are a lot of identically named and numbered sections... For example, there are several different sections titled "Furigana", each with a slightly different context. It was difficult to parse the sectional context when all the subsections were named the same.

To give more context, consider renaming the following:

• "2.1 Furigana" section to "2.1 Furigana Background",
• "3.1.1 Furigana" to "3.1.1 Furigana when both read aloud",
• "3.2.1 Furigana" to …
• "3.3.1 Furigana" to …

Same suggestion for the multiple sections labeled

• Gikun
• Unusual names of people and places
• Interlinear notes
• Ruby to indicate the reading of a foreign phrase in language books
• Double-sided Ruby

Note: First suggested in https://github.com/w3c/aria/issues/1620

[himorin]

Thank you for porting issue to this repository. I actually felt similar (and reorganization could be required), and would ask @murata2makoto to consider possible changes including proposed above.

[murata2makoto]

@cookiecrook @himorin Thank you for your suggestions. I am wondering if we should introduce a new section for the abstract model. I would like to change subsection titles when I reorganize the current structure.

[himorin]

(Reading through whole document again, and wondering this point...) It seems it is already suggested/proposed, but how about to reverse the division, from 'options of picking targets for reading' > 'examples' to 'examples' with list of readings for options, as well as adding a new section for abstract of models? Like:

Gikun

Results for an example <ruby><rb>生命</rb><rt>いのち</rt></ruby>

- reading both: "Seimei Inochi", where "Seimei" is a loan word from Chinese and "Inochi" is a native Japanese word. Both means life. 
- reading ruby annotation: "Inochi"
- reading ruby base: "Seimei"

The option of reading aloud both is sensible, although other two are not.
The option of reading aloud ruby annotation only provides an understandable result but does not properly convey the author's intention. In contrast, the option of reading aloud ruby base only results in a perfectly understandable result, but the author's intent is not completely conveyed since gikun is ignored.

With this, readers can easily compare what results TTS users will get, and could result to understand pros/cons over cases. @murata2makoto how about?

[murata2makoto]

@himorin

With this, readers can easily compare what results TTS users will get, and could result to understand pros/cons over cases.

This is true, but I have a concern. Doesn't your proposed reorganization make it difficult to compare the three options (both, ruby-only, or base-only)?

At present, implementations have no information about ruby roles. I can imagine that a short-term improvement is to avoid double-reading unless the user chooses it. In my opinion, the current structure makes it clear that such a change is an improvement.

[himorin]

I agree that one of important part is to avoid double-reading without having a mechanism of providing role of a target ruby, but if that is the most important point out of intentions of this document, I think neither the current structure nor proposed one would work since there is no summary pointing it as a whole over six roles (five plus double-sided?). I am not sure what difficult to compare the three options exactly means, but currently there are only a list of evaluations over fragmented places and I felt it is hard to tell which option is better per ruby role.

[murata2makoto]

if that is the most important point out of intentions of this document, I think neither the current structure nor proposed one would work since there is no summary pointing it as a whole over six roles (five plus double-sided?).

Agreed. How about adding a summary to each of 3.1, 3.2, and 3.3?

[himorin]

I suppose having both summary of each subsection and summary over entire comparison would be better for readers to tell concrete idea on pros/cons...?

[murata2makoto]

I suppose having both summary of each subsection and summary over entire comparison would be better for readers to tell concrete idea on pros/cons...?

I will give it a try.

[murata2makoto]

How about this?

2.Roles of ruby annotation 2.1 Furigana, background 2.2 Gikun, background 2.3 Unusual names of people and places, background 2.4 Interlinear notes, background 2.5 Ruby annotation to indicate the reading of a foreign phrase in language textbooks, background 2.6 Double-sided ruby, background

3. Which should be read aloud, base text or ruby annotation, or both? 3.1 Reading aloud both base text and ruby annotation 3.1.1 Furigana, when both read aloud 3.1.2 Gikun, when both read aloud 3.1.3 Unusual names of people and places, when both read aloud 3.1.4 Interlinear notes, when both read aloud 3.1.5 Ruby annotation to indicate the reading of a foreign phrase in language books, when both read aloud 3.1.6 Double-sided ruby, when both read aloud 3.2 Reading aloud ruby annotation only 3.2.1 Furigana, when ruby annotation read aloud 3.2.2 Gikun, when ruby annotation read aloud 3.2.3 Unusual names of people and places, when ruby annotation read aloud 3.2.4 Interlinear notes, when ruby annotation read aloud 3.2.5 Ruby annotation to indicate the reading of a foreign phrase in language books, when ruby annotation read aloud 3.2.6 Double-sided ruby, when ruby annotation read aloud 3.3 Reading aloud base text only 3.3.1 Furigana, when base read aloud 3.3.2 Gikun, when base read aloud 3.3.3 Unusual names of people and places, when base read aloud 3.3.4 Interlinear notes, when base read aloud 3.3.5 Ruby annotation to indicate the reading of a foreign phrase in language books, when base read aloud 3.3.6 Double-sided ruby, when base read aloud

[murata2makoto]

Done.