Template talk:ja-r

我が物顔
In the page of 我が, the word 我が物顔 is listed with this template but the ruby is incorrect: 我&#160;(わがもの) が 物顔&#160;(お) instead of the correct 我&#160;(わ<rp>)</rp> が 物<rp>&#160;(</rp><rt>もの</rt><rp>)</rp> 顔<rp>&#160;(</rp><rt>がお</rt><rp>)</rp>. How can I fix it? — T AKASUGI Shinji (talk) 03:19, 24 February 2014 (UTC)


 * There are two が in the kana string, so the module gets confused., 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 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   instead of  . It looks like it works here too:  —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

 * produces  instead of something like  . Please help. —suzukaze (t・c) 06:52, 15 September 2017 (UTC)
 * 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:

<blockquote style="border:1px solid gray; padding:4px;">This is a wrapper for 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 -- also impacts font size. Compare:



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,  , ... .

Currently, we can override the  argument to omit romaji. However, there is no way to omit the kana argument altogether -- alone just produces an error:

Consequently, the best workaround now is to use and  together. However, this results in different font sizes for the kanji, which is visually inconsistent and unnecessarily jarring.

, could any of you have a look at the guts of the relevant templates / modules and rejigger things so that either 1) (and/or ) produces the same font size for kanji as, or 2)  implements some means of omicodeing kana and rom altogether? As an example use case, have a look at  for the kutsu reading at 口, 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:

&#123;&#123;ja-r|ました|linkto=ます&#125;&#125;

I expected this to produce something like:



But instead I get this:


 * ます ( mashita  )

According to the documentation,  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)
 * 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)
 * 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)
 * Fixed. What caused the behavior in the original post was probably . — 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 :

In addition there is also. --Dine2016 (talk) 07:41, 15 March 2019 (UTC)


 * . —Suzukaze-c◇◇ 08:15, 15 March 2019 (UTC)
 * What is the problem in and ? As for  and, the period is simply ignored and a percent sign should be used instead in both the kanji and hiragana:  and . 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)
 * The problem with 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


 * 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 大<rt>オホ</rt>  長<rt>ハツ</rt>  谷<rt>セ</rt>  若<rt>ワカ</rt>  健<rt>タケ</rt>  &#x200b;<rt>ノ</rt>  命<rt>ミコト</rt>, as found in this Shōwa edition of the  (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)
 * 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:
 * No spaces in kanji field, full width space in furigana:
 * No spaces in kanji field, ASCII space in furigana:
 * No spaces in kanji field, ASCII space in furigana:
 * No spaces in kanji field, ASCII space in furigana:

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:



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



Adding in  symbols doesn't quite get there:



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



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
as: —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)