Template talk:ja-r

我が物顔

In the page of 我が, the word 我が物顔 is listed with this template but the ruby is incorrect: 我 (わがもの)が物顔 (お) instead of the correct 我 (わ)が物 (もの)顔 (がお). How can I fix it? — TAKASUGI Shinji (talk) 03:19, 24 February 2014 (UTC)

There are two が in the kana string, so the module gets confused. @Haplology, could you help, please? --Anatoli ^{(обсудить}/^вклад) 02:24, 13 March 2014 (UTC)

Romanization/transliteration

The romanization should be un-italicized, as the regular Template:l does not italicize romanizations. 〜britannic124 (talk) 19:38, 17 June 2014 (UTC)

Never mind. Template:l should be change to italics, rather. 〜britannic124 (talk) 23:58, 17 June 2014 (UTC)

Documentation

This template does not rely on {{l}} anymore but the documentation says that it does. —suzukaze (t・c) 08:51, 16 July 2015 (UTC)

屁

Sometimes it romanises 屁 as "e", as can be seen in the compounds section. Nibiko (talk) 19:13, 9 December 2015 (UTC)

A while ago I saw an anon use .は to generate ha instead of wa. It looks like it works here too: 沈香(じんこう)も焚(た)かず屁(へ)もひらず (jinkō mo takazu he mo hirazu) —suzukaze (t・c) 19:31, 9 December 2015 (UTC)

Wow! That's pretty interesting! Thanks for the fix ^^ Nibiko (talk) 00:10, 10 December 2015 (UTC)

linkto nothing

@Erutuon: diff produces [script needed] instead of something like ず (zu). Please help. —suzukaze (t・c) 06:52, 15 September 2017 (UTC)

@Suzukaze-c: Fixed. Just had to tell the module to use kana as alt text. — Eru·tuon 08:19, 15 September 2017 (UTC)

Documentation error -- mismatch in functionality with Template:l

The Documentation page states that:

This is a wrapper for {{l}} that does two things:

1. automatic romanization (which is italicized here and put in l's tr parameter)
2. placing of furigana aka ruby over the linked term (the term with furigana is put in l's third unnamed parameter)

The problem is that this is not just a wrapper -- {{ja-r}} also impacts font size. Compare:

• {{l|ja|実験}}: 実験
• {{ja-r|実験|じっけん}}: 実験(じっけん) (jikken)

Ignoring the ruby and romaji functionality, the two produce visibly different output for the kanji portion. This is a problem in cases where there might be a list of kanji spellings for the same kana and romaji rendering, where the kana are in no specific way related to the kanji spelling (irregular reading, jukujikun or other ateji), and where it makes more sense to list these as [KANJI_1], [KANJI_2], ... [KANJI_N] ([ROM]).

Currently, we can override the rom argument to omit romaji. However, there is no way to omit the kana argument altogether -- {{ja-r|KANJI}} alone just produces an error:

• 実験 (実験)

Consequently, the best workaround now is to use {{l|ja}} and {{ja-r}} together. However, this results in different font sizes for the kanji, which is visually inconsistent and unnecessarily jarring.

@Wyang, Suzukaze-c, Erutuon, Chuck Entz, could any of you have a look at the guts of the relevant templates / modules and rejigger things so that either 1) {{l|ja}} (and/or {{ja-l}}) produces the same font size for kanji as {{ja-r}}, or 2) {{ja-r}} implements some means of omicodeing kana and rom altogether? As an example use case, have a look at =====Derived terms===== for the kutsu reading at 口#Japanese, specifically the items with readings kutsuchi, kutsubami, and kutsuwa.

If there's a different approach that would work better, I'm all ears.

Thank you, ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:19, 11 October 2017 (UTC)

I think it would be better to put ruby on all three and then suppress the romaji for the first two. —suzukaze (t・c) 18:12, 11 October 2017 (UTC)

• It occurs to me, if the ruby don't actually correlate with any specific kanji (other than the single-kanji kun'yomi), it seems to me that there isn't really any value in including ruby at all... ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:09, 11 October 2017 (UTC)

• That's true, but I like the consistency. —suzukaze (t・c) 22:04, 11 October 2017 (UTC)

Change in behavior? "linkto=" param

I recently tried to use the following:

{{ja-r|ました|linkto=ます}}

I expected this to produce something like:

ました (mashita)

But instead I get this:

ます (mashita)

According to the documentation, linkto= should change the destination of the link, but without changing the text of the link.

What happened? ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:09, 20 March 2018 (UTC)

That is definitely not expected behavior. —suzukaze (t・c) 21:57, 21 March 2018 (UTC)

@Eirikr: My previous edit was at fault. At least the case above is fixed; let me know if there are other problems. — Eru·tuon 22:47, 21 March 2018 (UTC)

@Erutuon:: あいうえお (Ai ueo) shouldn't preserve the caret or space in the link. What edits caused these changes in behavior anyway? —suzukaze (t・c) 07:14, 23 March 2018 (UTC)

@Suzukaze-c: Fixed. What caused the behavior in the original post was probably this edit. — Eru·tuon 07:56, 23 March 2018 (UTC)

But how did no-one notice for so many months? 🤔 —suzukaze (t・c) 07:59, 23 March 2018 (UTC)

Dividing kana between kanji

I noticed the following on 王:

• 女王(じょおう) (joō), 女王(じょうおう) (jōō), 女王(にょおう) (nyoō, “queen”)

In addition there is also 昨日(きのう) (kinō). --Dine2016 (talk) 07:41, 15 March 2019 (UTC)

@Erutuon. —Suzukaze-c◇◇ 08:15, 15 March 2019 (UTC)

What is the problem in {{ja-r|女王|じょう.おう}} and {{ja-r|昨日|きのう}}? As for {{ja-r|女王|じょ.おう}} and {{ja-r|女王|にょ.おう|queen}}, the period is simply ignored and a percent sign should be used instead in both the kanji and hiragana: {{ja-r|女%王|じょ%おう}} and {{ja-r|女%王|にょ%おう|queen}}. I don't know enough about the usage of the period to say whether it could be used by the modules to determine which hiragana go with which kanji. — Eru·tuon 23:36, 15 March 2019 (UTC)

I guess the treatment of にょおう could be improved, because generally the vowel sound o is lengthened with う and not with お, right? — Eru·tuon 23:39, 15 March 2019 (UTC)

It would be helpful to have testcases for ruby addition, so that these problems can be more transparently debugged. — Eru·tuon 23:41, 15 March 2019 (UTC)

@Erutuon: The problem with {{ja-r|昨日|きのう}} is that it is a 熟字訓, so there should be no matching of kana with kanji. Kana should be divided evenly. --Dine2016 (talk) 09:52, 3 July 2019 (UTC)

Moreover, there was no matching of kana with kanji in the past, so many editors typed without %'s. When auto-matching of kana with kanji was added, it broke many pages. For example, take a look at 生 and you'll find

#: {{ja-usex|生糸|き.いと|'''raw''' silk}}

which has existed since 2017. In the past there was no auto-matching of kana with kanji, so it used to be displayed evenly: 生糸(きいと). When auto-matching was added, it was displayed incorrectly: 生糸(きいと). Correct auto-matching of kana with kanji is better than no matching of kana with kanji, but no matching of kana with kanji is better than wrong matching of kana with kanji. So when adding auto-matching of kana with kanji, make sure to either get it 100% right (for example, use a 漢字音訓表 to determine whether 生糸 is き + いと or きい + と), or find and correct older uses of ruby which the new module gets wrong. --Dine2016 (talk) 10:02, 3 July 2019 (UTC)

• (chiming in)

There's also the interesting use case where the kana includes a の that is intentionally left implied, and which doesn't correspond to any of the kanji. This happens more with fossilized compounds and names, or in older texts. One example is 大オホ長ハツ谷セ若ワカ健タケ​ノ命ミコト, as found in this Shōwa edition of the Man'yōshū (left-hand page of the two shown). If you view the wikisource of my post here, you'll see that I've directly input the HTML tags, and used a non-breaking zero-width space ​ as the "body" character for the ノ that doesn't belong to any kanji. I don't know how this could be specified as an argument in a template call, however, in a way that would be easily understood by users. ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:16, 3 July 2019 (UTC)

Removed automatic dividing-up of kana, unless either of you have a different suggestion for handling the cases where kana should apply to multiple kanji. — Eru·tuon 16:21, 3 July 2019 (UTC)

Accept full width spaces

The following differ only in the use of a Japanese-type full width space ('　") vs. a Western-type ASCII space ( ):

• Full width in kanji & furigana fields:

  黒(くろ)枡(マス)　は　どこ　だ？ (Kuromasu wa doko da?, “Where are the black cells?”)

• No spaces in kanji field, full width space in furigana:

• No spaces in kanji field, ASCII space in furigana:

  黒(くろ)枡(マス)はどこだ？ (Kuromasu wa doko da?, “Where are the black cells?”)

These should all have the same furigana / ruby outcome (except adding spaces to the Japanese text in the first example).

I suggest that the template be edited to interpret full width space as identical to ASCII space, since switching keyboard types for each is unnecessarily complicated and results in obtuse errors. Saizai (talk) 11:33, 26 October 2021 (UTC)

Possible to suppress matching?

Sometimes the ruby and the base text have almost nothing to do with each other, particularly when it comes to how text is used in manga, games, and other aspects of pop culture.

Consider this Yu Gi Oh game edition title, as shown here:

• 決闘王の記憶 － 決闘者の王国編

The ruby for this title are given as:

• デュエルキングのきおく － デュエリスト・キングダムへん

I can get the first half to line up:

• {{ja-r|linkto=-|決闘 王 の 記憶|^デュエル ^キング の ^きおく}}
• 決闘(デュエル)王(キング)の記憶(きおく) (Dyueru Kingu no Kioku)

... but the second half is defeated by the template trying, in vain, to match the の with anything:

• {{ja-r|linkto=-|決闘者の王国-編|^デュエリスト・^キングダム-へん}}

Adding in % symbols doesn't quite get there:

• {{ja-r|linkto=-|決闘者の王国%-編|^デュエリスト・^キングダム%-へん}}

Even more-aggressive percent-adding doesn't do it either:

• {{ja-r|linkto=-|決闘者%の%王国%-編|^デュエリスト%・%^キングダム%-へん}}
• 決闘者(デュエリスト)の(・)王国(キングダム)-編(へん) (Dyuerisuto Kingudamu-hen)

Is there any way to suppress the matching check? I actually want the の and the ・ to align here. I don't need or want the module to try to second-guess me. ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:17, 25 January 2023 (UTC)

linkto is broken

@Theknightwho as:

• るるちゃんの自(じ)殺(さつ)配(はい)信(しん) (Ruru-chan no jisatsu haishin)

—Fish bowl (talk) 22:17, 23 March 2023 (UTC)

And also as seen in the previous section above. —Fish bowl (talk) 22:26, 23 March 2023 (UTC)

@Fish bowl linkto should be fixed now. Not sure I know enough about the rubytext module to fix the other issue. Theknightwho (talk) 22:26, 23 March 2023 (UTC)