Would ruby annotation support for CJKV languages be in scope?

[llkem]

Hello, I am interested in whether ruby characters
would be in the scope for the Comrak software as an extension, optionally.
The primary use case would be for Japanese and Chinese characters, with the reading
displayed above the character.
The secondary use would be for Korean, Classical Chinese, Old Vietnamese (Chữ Nôm),
and annotations for language learners.

These ruby characters are already in use throughout the sinosphere,
and current Japanese, Chinese, Korean, and Vietnamese commuties have to suffer through
workarounds such as putting the preferred reading in parethases like so: 漢字（かんじ）.
This method works in all major enviroments, but terribly interrups the -flow - of reading a passage,
is worse for longer text, and is unfamiliar to most CJKV users, especially less informed, older users,
non -technical users, or ones accustomed to ordinary CJKV typography
adding just another hurdle to usability and internationalization.
I'd be happy to gather real examples, from daily life to government documents, art, novels, historical research,
language learning, comics, etc from Japanese/Chinese/Korean/Vietnamese communities if that would
help evaluate the feature.

Hopefully, there could be some lightweight Markdown syntax that would render to HTML Ruby tags.
The syntax could be whatever fits the Comrak or CommonMark ethos the best.
One example could look like so:
The user types:
{漢字|かんじ}
this could render internally as :

<ruby>漢字<rt>かんじ</rt></ruby>

As another option, Comrak could render the ruby with "fallback" <rp> tags,
allowing older/unsupportive clients to fallback to parentheses.
i.e.:

<ruby> 
漢字 <rp>(</rp> <rt>かんじ</rt><rp>)</rp>
</ruby>

renders to the correct furigana when supported, and 漢字（かんじ）when unsupported.

The main question I have is would this feature be acceptable as an optional extension, or is this
way outside the extended scope of Comrak?
Also, if it does end up being in -scope, what kind of constraints would matter most?
For example, security concerns, avoiding ambiguity with existing syntax, etc.

As a close, i don't have any expectations for you personally implementing this, i'm just trying
to understand if this is a feature that would belong in Comrak at all before anyone
spends considerable effort on it.

Thank you for your time!

Further reading / references

• MDN: <ruby> element
  https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/ruby
• MDN: <rt> element
  https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/rt
• MDN: <rp> element
  https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/rp
• WHATWG HTML Standard: text -level semantics, including ruby, rt, and rp
  https://html.spec.whatwg.org/multipage/text-level-semantics.html
• W3C / WAI: WCAG Technique H62, “Using the ruby element”
  https://www.w3.org/WAI/WCAG21/Techniques/html/H62
• W3C Internationalization: Ruby Markup
  https://www.w3.org/International/articles/ruby/markup.en.html
• W3C Internationalization: Ruby Styling
  https://www.w3.org/International/articles/ruby/styling.en.html
• CSS Ruby Annotation Layout Module Level 1
  https://www.w3.org/TR/css-ruby-1/
• CommonMark forum discussion: ruby text / furigana syntax in Markdown
  https://talk.commonmark.org/t/proper-ruby-text-rb-syntax-support-in-markdown/2279
• Example implementation: markdown -it -ruby
  https://github.com/lostandfound/markdown-it-ruby
• Example implementation: furigana -markdown -it
  https://github.com/iltrof/furigana-markdown-it

[kivikakk]

Hiya! Thank you for opening this discussion :) I only have time for a brief reply so let me just say thank you for your very complete proposal and references!

I'm 100% open to adding ruby annotation support as an extension to Comrak, absolutely :)

I'm partial to the {ruby base|ruby text} syntax in your example and as shown in the markdown-it-ruby reference you've given, particularly as it itself has reference to a spec (which shows syntax for both ruby text across the entire base, and per-character ruby; one may like to add support just the first of these, or even both!).

For example, security concerns, avoiding ambiguity with existing syntax, etc.

The biggest consideration for contributions to Comrak is our contributions policy; the main thing is that I'm happy to look over PRs at any stage of completion, and will also be happy to help work with contributors to get to the final end result; Comrak is a community project as much as it is an actual software artefact. The only requirement is that LLMs are not used to create the code.