Blog Entries

The Case for Furigana

2021/11/08 20:52 · admin ·

This is largely a rewriting of the original case I lifted for the use of ruby / Furigana annotations in English for story writing, such as fanfics, originally submitted for the PokéCommunity forum. Only now it's reformatted and made publicly available in order to support the feature request in other communities and cases.

The idea is, English is good at taking stuff from other languages. Why not take then from East Asian languages the concept of annotations to enhance pronunciation, semantic meaning and other features of text communication?

FYC: Support Furigana Annotations

Hello everyone. For your consideration:

It would be of interest to count in ${COMMUNITY_NAME} 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.

This feature request, as well as its submission to a number of forums and communities, can be tracked at this Fandom.ink (Mastodon) thread.

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 PC [PokéCommunity].

Implementation

The implementation of ruby in forums or mediums that use HTML directly or use an intermediate dialect or subset, such as Archive of Our Own, is quite simple: just add the < ruby > related elements to the list of allowed components in the parser.

The absolute minimum set of required elements is as follows:

<ruby> , <rt> , <rp>

Strangely enough, on AO3 (Archive of Our Own) these tags already work — on the drafting views. Once you reload a draft or once you post to published work however, not only are the ruby elements lost but their semantic separation from the surrounding content as well; I figure out there is some sort of bug about it, so I've sent a bug report / feature request to AO3 dated 2021-10-25. Let's see what happens.

The implementation of ruby in BBCode compatible forums is also quite simple and 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:

[ruby={TEXT1}]{TEXT2}[/ruby]
<ruby class=".... ruby">{TEXT2}<rp>(</rp><rt>{TEXT1}</rt><rp>)</rp></ruby>

(note here that the parenthesis element is not provided by the user and instead we generate it directly; this is mostly useful to keep the BBCode tag simple)

2.- Mapping the [ ruby ], [ rb ] 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:

[ruby]{TEXT}[/ruby]
<ruby class=".... ruby">{TEXT}</ruby>
[rt]{TEXT}[/rt]
<rt>{TEXT}</rt>
[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:

This weird animal is a ñandú(nyan·DOO)

And here is a saved picture in case you can't see it:

furigana_sample.jpeg

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 this 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 my thread "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:

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. 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 forums may or may not, on their own, have different mechanisms to provide such asides. For example, the [ spoiler ] tag and the [ title ] tag are implemented in PokéCommunity, and the [ highlight ] tag in Thousand Roads. However, [ ruby ] is superior to all of them for its intended purpose for several reasons:

  • ruby is a HTML standard: once implemented, ${COMMUNITY_NAME} doesn't really have to care about anything else, it is solved client-side by the web browser. Even Internet Explorer implemented it back in the time.
  • ruby is more accessible than [ title ] tags, that are not visible or accessible on mobile and do not survive a print mode or reader mode either
  • ruby is more accessible than [ spoiler ] tags, as those need to be explicitly opened and they are not otherwise operable in an offline dump without Javascript; they also break content flow and don't survive print or reader mode renders.
  • ruby renders client-side within the viewer's paragraph layout and 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 a number of points above, ruby works in “flat” renders, such as print preview mode, Save As…., etc, where most other layout and presentation decorations such as table borders, background colours 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 a number of communities, including Archive of Our Own. For many forum systems and fanfic publication sites, iImplementing this feature would provide an important bonus to accessibility, readability and expandability of the content.

At the time of last edition of this document I'm still waiting for a response from AO3, but I will be reporting over at Fandom.ink on the results and advances on implementation.

Test

2021/11/08 17:18 · admin ·

This is a test. If it's successful… I guess I have an excuse for doing stuff.


Hosting provided by the tropi.us community.