Venia Silente
For your ills, I prescribe a cat.
Hello everyone. For your consideration:
It would be of interest to count in Thousand Roads with support for <ruby>, the HTML standard tag for Furigana annotations. These annotations are used in East Asian languages in order to provide inline information such as pronunciation guides (crossing between Kanji and Katakana, for example), but not only that! For fanfic writers specially, this capability would be a boon to add to stories that deal in heavy semantic worldbuilding, that import elements from other cultures and languages, etc.
How furigana annotations work in HTML is by introducing a tag, < ruby >, that marks a set of text to be annotated plus the annotation itself; sub-tags < rp > and < rt > denote the base text, the parenthesization delimiter for the annotation, and the annotation text itself respectively. Unlike with other HTML elements such as <span title="..."> that are displayed by the web render as an overlay and do not form part of the text's "content", ruby does form part of the text content, and in most browsers it is rendered inter-line, or in-line when inter-lining is not available.
For examples of how ruby can be used in English check this tweet as well as its associated conversations. I'm at the moment attempting to also unlock this pending power in AO3, and at least two more forums besides TR.
The implementation of ruby in TR, and really in *any* BBCode compatible forum, could be done in one of at least two alternatives that hereby I introduce:
1.- A dedicated [ ruby ] tag alone with the annotation as attribute: using here phpBB definition language for the tag, it would look like this:
(note here that the parenthesis element is not providedn instead, we generate it directly; this is mostly useful to keep the BBCode tag simple)
2.- Mapping the [ ruby ] and [ rt ] tags (as well as optionally a tag for the [ rp ] element) to their HTML equivalents: using here phpBB definition language for the tag, it would look like this:
(note here that the rp element uses SIMPLETEXT instead of TEXT; for those not versed in phpBB's DDL for BBCode, this basically means that the parentheses elements should contain simple ASCII or similar text, such as... well, parentheses, and it's mostly useful for sanitization)
Here's what the implementation would look like on a web renderer:
A browser that can't render inter-line (for example a print-preview or a text reader for accessibility) will render the annotation in-line by the side of the word, using the parentheses in <rp> tags as delimiters, for example ñandú (nyan·DOO).
For fanfic writers mostly, a ruby annotation tag can be useful in any of four ways. Most of them relate to one aspect of writing and worldbuilding that is not often given much consideration: if you want to add a note regarding some elements in your story, such as footnotes, translations or definitions of new terms, pronounciation guides, or reminders, it can be the case that the explanation you are going to give does not go into the story itself, but rather several lines or even pages ahead, in an Author's Notes section, severely breaking immersion and forcing readers to basically keep two copies of your work open to course about. I've actually expanded on this subject in PokéCommunity: "Writing† and Explaining in the Cybermesh¹: How to Make it Accessible²?".
But fear not! Ruby annotations make this so much easier:
1.- Pronunciation
Not much to say here; the example I've posted above mostly speaks (heh) for itself. This means a reader gets information of how to pronounce a new term (such as a character's or location's name) as soon as it's introduced, without breaking pace or immersion in the story, and more importantly in a mechanism that is automatically also available for eg.: screen readers, audiobooks and accessibility readers.
For a further example observe here:
image
2.- Translation
Similar to the above, for those authors who like to introduce elements with basis from different languages, it is possible to introduce these definitions as early as they are used. Stories like Fledglings, that heavily deal in foreign expressions, could benefit from this. Consider for example the following:
3.- Semantic Meaning
As we all know, things like sarcasm don't... really translate well into a text medium. But thanks to furigana, we can add semantic tags to dialogue to provide hints on sarcasm level, emphatic state, falsehood level, etc:
4.- Reminders
In written medium it tends to be the case that we need to refer to events in previous chapters, or even in different stories altogether. For example in comics, when Spiderman is fighting Magneto he comments, with an asterisk, that the last time they fought at least he had some help (and down the panel, a text box with the asterisks explains that this happened in Spiderman and the Fantastic Four Crossover Adventures IV, page 36). In comics this works because there's not much visual distance between the content and the note: they tend to be in the same panel or at least in the same page; in the world of fanfiction, such a note would require readers to wait out, or to scroll and then try to get back, to the Author's Notes section. But not with furigana!
This particular form is notoriously less useful than the others, since if the commentary is long enough an aside note next paragraph or at the end of page (for paged works) is more readable, but once again, those methods don't really work well in the continuous paging, page-below-thread model that stories on web forums follow. I placed it here mostly for completeness.
Now, it is true that some BBCode forums may or may not, at their own discretion, have different mechanisms to provide such asides. For example, the [ spoiler ] tag that creates a block that must be explicitly expanded to view the content, and the [ title ] or [ highlight ] tags that implement on-hover /on-focus overlay for text descriptions. However, [ ruby ] is superior to both of them for its intended purpose for several reasons:
But hey, this is mostly it! I hope this makes a good case for adding this feature to the forum, and if I'm lucky also to AO3 once they get back in touch. It would provide an interesting boon to accessibility and expandability of contentand to my plans of world domination.
As per input from kibigo and further (heavier) check on MDN, I'm editing this post to fix the proposal as follows:
* replacement and editing of the < rb > element (now deprecated) is removed.
It would be of interest to count in Thousand Roads with support for <ruby>, the HTML standard tag for Furigana annotations. These annotations are used in East Asian languages in order to provide inline information such as pronunciation guides (crossing between Kanji and Katakana, for example), but not only that! For fanfic writers specially, this capability would be a boon to add to stories that deal in heavy semantic worldbuilding, that import elements from other cultures and languages, etc.
Furiwhat?
How furigana annotations work in HTML is by introducing a tag, < ruby >, that marks a set of text to be annotated plus the annotation itself; sub-tags < rp > and < rt > denote the base text, the parenthesization delimiter for the annotation, and the annotation text itself respectively. Unlike with other HTML elements such as <span title="..."> that are displayed by the web render as an overlay and do not form part of the text's "content", ruby does form part of the text content, and in most browsers it is rendered inter-line, or in-line when inter-lining is not available.
For examples of how ruby can be used in English check this tweet as well as its associated conversations. I'm at the moment attempting to also unlock this pending power in AO3, and at least two more forums besides TR.
Implementation
The implementation of ruby in TR, and really in *any* BBCode compatible forum, could be done in one of at least two alternatives that hereby I introduce:
1.- A dedicated [ ruby ] tag alone with the annotation as attribute: using here phpBB definition language for the tag, it would look like this:
Code:
[ruby={TEXT1}]{TEXT2}[/ruby]
<ruby class=".... ruby">{TEXT2}<rp>(</rp><rt>{TEXT1}</rt><rp>)</rp></ruby>(note here that the parenthesis element is not providedn instead, we generate it directly; this is mostly useful to keep the BBCode tag simple)
2.- Mapping the [ ruby ] and [ rt ] tags (as well as optionally a tag for the [ rp ] element) to their HTML equivalents: using here phpBB definition language for the tag, it would look like this:
Code:
[ruby]{TEXT}[/ruby]
<ruby class=".... ruby">{TEXT}</ruby>
Code:
[rt]{TEXT}[/rt]
<rt>{TEXT}</rt>
Code:
[rp]{SIMPLETEXT}[/rp]
<rp>{SIMPLETEXT}</rp>(note here that the rp element uses SIMPLETEXT instead of TEXT; for those not versed in phpBB's DDL for BBCode, this basically means that the parentheses elements should contain simple ASCII or similar text, such as... well, parentheses, and it's mostly useful for sanitization)
Here's what the implementation would look like on a web renderer:
A browser that can't render inter-line (for example a print-preview or a text reader for accessibility) will render the annotation in-line by the side of the word, using the parentheses in <rp> tags as delimiters, for example ñandú (nyan·DOO).
What is a ruby tag useful for?
For fanfic writers mostly, a ruby annotation tag can be useful in any of four ways. Most of them relate to one aspect of writing and worldbuilding that is not often given much consideration: if you want to add a note regarding some elements in your story, such as footnotes, translations or definitions of new terms, pronounciation guides, or reminders, it can be the case that the explanation you are going to give does not go into the story itself, but rather several lines or even pages ahead, in an Author's Notes section, severely breaking immersion and forcing readers to basically keep two copies of your work open to course about. I've actually expanded on this subject in PokéCommunity: "Writing† and Explaining in the Cybermesh¹: How to Make it Accessible²?".
But fear not! Ruby annotations make this so much easier:
1.- Pronunciation
Not much to say here; the example I've posted above mostly speaks (heh) for itself. This means a reader gets information of how to pronounce a new term (such as a character's or location's name) as soon as it's introduced, without breaking pace or immersion in the story, and more importantly in a mechanism that is automatically also available for eg.: screen readers, audiobooks and accessibility readers.
For a further example observe here:
image
2.- Translation
Similar to the above, for those authors who like to introduce elements with basis from different languages, it is possible to introduce these definitions as early as they are used. Stories like Fledglings, that heavily deal in foreign expressions, could benefit from this. Consider for example the following:
3.- Semantic Meaning
As we all know, things like sarcasm don't... really translate well into a text medium. But thanks to furigana, we can add semantic tags to dialogue to provide hints on sarcasm level, emphatic state, falsehood level, etc:
4.- Reminders
In written medium it tends to be the case that we need to refer to events in previous chapters, or even in different stories altogether. For example in comics, when Spiderman is fighting Magneto he comments, with an asterisk, that the last time they fought at least he had some help (and down the panel, a text box with the asterisks explains that this happened in Spiderman and the Fantastic Four Crossover Adventures IV, page 36). In comics this works because there's not much visual distance between the content and the note: they tend to be in the same panel or at least in the same page; in the world of fanfiction, such a note would require readers to wait out, or to scroll and then try to get back, to the Author's Notes section. But not with furigana!
This particular form is notoriously less useful than the others, since if the commentary is long enough an aside note next paragraph or at the end of page (for paged works) is more readable, but once again, those methods don't really work well in the continuous paging, page-below-thread model that stories on web forums follow. I placed it here mostly for completeness.
Comparison to other techniques
Now, it is true that some BBCode forums may or may not, at their own discretion, have different mechanisms to provide such asides. For example, the [ spoiler ] tag that creates a block that must be explicitly expanded to view the content, and the [ title ] or [ highlight ] tags that implement on-hover /on-focus overlay for text descriptions. However, [ ruby ] is superior to both of them for its intended purpose for several reasons:
- ruby is a HTML standard: once implemented, a forum doesn't really have to care about anything else not even the styling, it is solved client-side by the web browser. Even Internet Explorer implemented it back in the time.
- ruby is more accessible: [ title ] tags are not visible or accessible on mobile, or on screenreaders, and definitively not visible in printouts or exports; [ spoiler ] tag blocks need to be explicitly opened and they are not otherwise operable in an offline dump without Javascript, and they also break content flow. Whereas ruby renders client-side within the viewer's paragraph layout model, be it inter-line or in-line to the viewer (and thus the reader)'s convenience.
- ruby degrades gracefully: if the render can not present it inter-line, it will present it in-line automagically, using the ruby parentheses as delimiters. This is also readable for machines, which means it's easier to adapt for eg.: audiobooks.
- Because of points 1 and 2 above, ruby works in "flat" renders, such as print preview mode, Save As, or export to PDF, where most other layout and presentation decorations such as table borders, background colors or spoiler blocks are disabled.
To close
But hey, this is mostly it! I hope this makes a good case for adding this feature to the forum, and if I'm lucky also to AO3 once they get back in touch. It would provide an interesting boon to accessibility and expandability of content
Amendments
As per input from kibigo and further (heavier) check on MDN, I'm editing this post to fix the proposal as follows:
* replacement and editing of the < rb > element (now deprecated) is removed.
Last edited:
