Would the furigana extension here also be suitable for adding pinyin on Chinese Language & Usage?

Question

Over on Chinese Language & Usage I started a meta topic yesterday on whether we might consider using the furigana extension from Japanese Language & Usage to add pinyin above characters just as here it's used to add kana above characters.

Example question from CL&U:

What's the difference between “大衣” (dàyī), “外套” (wàitào), and “外衣” (wàiyī) - which can all be translated to “coat”?

The same example question using the JL&U furigana extension:

What's the difference between 大衣{dàyī}, 外套{wàitào}, and 外衣{wàiyī} - which can all be translated to “coat”?

But I see it doesn't work "out of the box". Is it hard-coded to detect kana characters only between the { and }, or does it treat Latin characters specially, making it difficult to work with Pinyin which is also in the Latin alphabet?

For CL&U users to see how it would work, here's one of my old JL&U question titles but with furigana added:

When to use ください or お願{ねが}いします in requests?

Answer 1

The Chinese SE community would definitely benefit from a modified version of the furigana extension here. I'll make a list of concerns that is based on user senshin's points from a draft mockup a while back and the current Japanese Meta formatting page.*

_{*Apologies for posting here, but Japanese SE has the best (and only) support for ruby text, so it's easiest to demonstrate the functionality here.}

---

removed support for okurigana and pitch accent

Agree, Chinese doesn't have/need this (although see Point 19).

added auto-conversion for things like zhong1wen2 to zhōngwén

Agree to this feature conditionally - we need an easy way to turn the conversion feature off.

1. Agree that this needs to be a core feature, because

   1. The tone marks on letters ā é ǐ ò and the umlaut ü are difficult to type on a standard keyboard

2. Condition: we need an easy way to turn it off (not on), because

   1. The majority of questions or answers which are going to use this feature are probably going to be based on new learners of Chinese using Mandarin Pinyin (I don't know how to use bopomofo, but if tone marks are difficult to type there we should support that too). Making the feature default is more useful than making the user turn the feature on.

   2. I like the idea of using numbers as the indicator to convert to the tone mark, but many non-Standard-Mandarin topolects use numbers to represent tone as well, without using the Mandarin notation of tone. Truncated example (from Wiktionary entry of 「你」):

      • Mandarin

         (Chengdu, SP): nyi³

      • Cantonese

         (Guangzhou, Jyutping): nei⁵

         (Taishan, Wiktionary): nei¹, nei⁴

      • Gan: n³

      Other topolects may also have different standards of where to put the tone, if it uses the same tone symbols (and probably won't correspond to the Mandarin notation of numbers 1 to 4):

      • Hakka

         (Sixian, PFS): ngì / ǹ / ǹg / nì

      • Min Bei (KCR): nì

      • Min Dong (BUC): nī

If you include the pinyin in "numeric" form (like the second and fourth examples above), it will also automatically be segmented so that each syllable is placed above its corresponding character.

Agree to this feature conditionally. If numbers are overloaded to be a way to also segment syllables, we should be able to turn off the feature (e.g. by escaping it).

3. We need to address the neutral tone with either a "0" or "5".

4. We need to be able to turn it off due to the rare presence of multi-syllable characters, e.g. 「[圕]{túshūguǎn}」.

Can pinyin written in "diacritic" form (like the first and third examples above) be unambiguously broken into syllables (by itself, without reference to the characters)? If so, I can figure out how to implement automatic segmentation for diacritic-form pinyin.

Disagree with this feature, as Pinyin (with or without diacritics) cannot be broken unambiguously. In Pinyin,

6. The neutral tone (see Point 3) calls for the absence of any diacritics.

7. Tone diacritic marks always go above the vowel or one of the letters in a diphthong, regardless of what the syllable is, so syllable-final [-ng] cannot be unambiguously segmented from syllable initial [g-]; e.g. it is ambiguous whether [bangan] refers to [ban gan] or [bang an].

8. How do we turn it off for multi-syllable characters (see Point 4)?

Does this site cover Chinese languages besides Mandarin, and if so, would there be any demand for tonal annotations for other languages?

Yes, but currently I would suggest not to try to implement a topolect-specific version of those, otherwise the syntax is going to be too messy. See what the tone orthography could look like in Point 2.

9. A basic kind of support would be to reuse the Pinyin syntax with numbers for both tone marking and syllable segmentation, but replace the tone marks on the vowel/diphthong with a superscript number after the syllable.

   • [你好]{ni3hao3} should be rendered as [你]{nǐ}[好]{hǎo} in Mandarin Pinyin

   • [你好]{nei5hou2} should be rendered as [你]{nei⁵}[好]{hou²} in Cantonese Jyutping

   • A similar conversion to the Cantonese above should be used for a lot of other non-Mandarin topolects (see Point 2)

Are there any characters that would require annotation outside the UTF-8 range from U+4E00 to U+FEED? That's what JLU uses, and it seems to cover all common CJK characters, but the CJK Unified Ideographs Extension ranges fall outside that, and I don't know if you folks would need that.

I don't know what the current Japanese SE support is, but as a minimum, we need:

10. Support for IPA symbols
11. Support for superscript numbers and letters (if not already part of IPA)

12. Support for the standard CJK range from U+4E00 to U+FEED (annotating Chinese characters with other Chinese characters is standard practice of Fanqie for Middle Chinese)

    Japanese SE already supports this

13. The ability to annotate the following character sets outside of the standard CJK range with all of the above:

    1. Ideographic description characters

       Japanese SE already supports this

       [⿱戈止]{武}

    2. As many of the CJK Unified Ideograph Extensions as possible

       Japanese SE already supports annotating characters up to CJK Unified Ideographs Extension F, which is currently very sufficient

       [𮯠]{I don't know the reading of the character U+2EBE0}

    3. CJK Compatibility Ideographs

       Japanese SE already supports this

       [龎]{/*[b]ˤroŋ/}

       However, CJK Compatibility Ideographs have some funky display issues (at least on my computer)

Nice to have (not crucial):

14. Support for Vietnamese Quốc ngữ both ways

    Japanese SE already supports this

    • [𤾓]{Trăm}[𢆥]{năm}[𥪞]{trong}[𡎝]{cõi}[𠊛]{người}[些]{ta}

    • [Chữ]{𡦂} [tài]{才} [chữ]{𡦂} [mệnh]{命} [khéo]{窖} [là]{羅} [ghét]{恄} [nhau]{饒}

15. Support for ideographic description characters inside the annotation

    Japanese SE already supports this

    [𨷯]{⿵門舉}

16. Support for as many of the CJK Unified Ideograph Extensions as possible inside the annotation

    Japanese SE already supports annotations with characters up to CJK Unified Ideographs Extension F, which is currently very sufficient

    • [𤲮]{⿰田𢏚}
    • [𮯠]{𮯠}

17. Support for CJK compatibility ideographs inside the annotation

    Japanese SE doesn't support this fully

    • [齃]{齃} (from typing [齃]{齃})
    • [a齃a]{a齃a} (from typing [a齃a]{a齃a})

---

Other features taken from the Japanese Meta formatting page (nice to have)

18. Furigana padding

19. Modifying the pitch accent mechanism specifically for emphasising text - can we get a black any-coloured squiggly line?

    

    This emphasis is often used in literature to mark proper nouns.

---

Points not addressed (needs further input from the community)

On JLU, there's also support for annotations of the form 神【かみ】 (in addition to square brackets []) because that's how dictionaries do it.

---

On JLU, the following characters behave like punctuation for the purposes of the helper script: .、。－-／｡＜＞（）()≪≫；;：:！!＝=≡≠≒＄￥？\?＆＃#＠@“‘”’. Are there any additional punctuation characters for Chinese?

Answer 2

Yes, the current regex won't work with romaji either. It checks for the presence of kanji before the curly brace, and kana inside it. It really should be easy enough for the devs to change it to support pinyin ruby (the requirement for kanji before the brace should make it specific enough to avoid any false detection).

Take it to your mods, I guess.

Answer 3

It seems like it can function in Chinese as is:

What's the difference between [大衣]{dàyī}, [外套]{wàitào}, and [外衣]{wàiyī} - which can all be translated to “coat”?

It would be nice to have at Chinese.SE. user3306356♦ reported it as added to the "Community Management Team's backlog".