Defining information sources for spoken presentation

[murata2makoto]

This issue aims to define what kinds of information user agents and assistive technologies should consider when generating spoken presentation of content containing ruby annotations.

The discussion in #12 (“Reading aloud ruby without reading aloud ruby base”) revealed that various factors — such as ruby bases, ruby annotations, particle pronunciation, and morphological analysis — can influence how text-to-speech output should be generated. However, #12 has become too long and mixed with broader topics.

This new issue focuses specifically on identifying these information sources, without prescribing any algorithmic behavior or implementation details.

Another issue (#59, "Clarifying the scope of this TR (informative, not algorithmic)") aims to make clear what is and what is not within the scope of this document.

[murata2makoto]

I would like to propose a new section between Alternatives to ruby and Use of ruby for automatic braille translation.

6. Information sources for generating spoken presentation

This section consolidates the discussion from previous sections and identifies the types of information that user agents and assistive technologies should consider when generating spoken presentation of content containing ruby annotations.

These information sources include, but are not limited to:

• Ruby base
• Ruby annotation
• Morphological analysis (for particle pronunciation and word segmentation)
• Contextual reuse of ruby base/annotation pairs
• Author-supplied pronunciation hints (e.g., via PLS or SSML)
• Heuristics or AI-based inference for legacy content lacking explicit semantics

In many cases, multiple sources of information may be considered together. For example, morphological analysis of the ruby base may affect how adjacent particles are pronounced, while PLS or SSML data may override default pronunciations. Inconsistencies between ruby base and annotation can also provide clues for determining whether the ruby is phonetic or non-phonetic in nature.

In summary, spoken presentation of content containing ruby annotations may be informed by multiple layers of information, including linguistic, typographic, and author-supplied data. This document identifies those information sources, but intentionally does not prescribe the algorithms or weighting mechanisms by which they are used. Such implementation decisions are expected to evolve through heuristics, rule-based systems, or AI-based approaches, and documented elsewhere.

[himorin]

note, due to recently happening BSoD of my main note pc, I've got several sudden failure of Windows, and sorry if some wrote text has been vanished...

I would like to propose a new section between Alternatives to ruby and Use of ruby for automatic braille translation.

just for clarification, does these link mean section 5 and 6 in the Draft Note? https://w3c.github.io/ruby-t2s-req/#alternatives-to-ruby
Per text wrote, I believe so, but just confirmation.

For text or section organization itself, I felt somehow confused of mixing complexity with reading both issues around marking up (or semantics?) and context, especially for examples in section 3 and this new proposed section. I personally believe we could divide to layers, 1) how we should semantically markup, analyze, and use by RS, such as additional information by aria-* using PLS or else, or even usage of mono-ruby or something, and 2) what is the attached ruby itself means among pronunciation, highly context dependent replacement of words, and interlinear annotations, including widely spread misleading discussion with mixing ruby itself and inline notes (or interlinear annotations).

[murata2makoto]

@himorin

just for clarification, does these link mean section 5 and 6 in the Draft Note? https://w3c.github.io/ruby-t2s-req/#alternatives-to-ruby
Per text wrote, I believe so, but just confirmation.

Right. I fixed my comment above.

[murata2makoto]

For text or section organization itself, I felt somehow confused of mixing complexity with reading both issues around marking up (or semantics?) and context, especially for examples in section 3 and this new proposed section. I personally believe we could divide to layers, 1) how we should semantically markup, analyze, and use by RS, such as additional information by aria-* using PLS or else, or even usage of mono-ruby or something, and 2) what is the attached ruby itself means among pronunciation, highly context dependent replacement of words, and interlinear annotations, including widely spread misleading discussion with mixing ruby itself and inline notes (or interlinear annotations).

Thanks for this suggestion.

I do not want to introduce such layers, however, since such layers are so close to algorithms. To me, they are outside the scope of this TR.

I am trying to create a pull request. Please have a look at it.