Template talk:Nihongo

Comma and semicolon separator

I request a method to specify the separator used between the Japanese text and extra parameter for use in the lead paragraphs, as it currently is not possible. take the following text:

Satoru Iwata (Japanese: 岩田 聡, Hepburn: Iwata Satoru, December 6, 1959 – July 11, 2015) was ...

the correct formatting would be with a semicolon, not a comma, after the Hepburn romanization and before the date.

Satoru Iwata (Japanese: 岩田 聡, Hepburn: Iwata Satoru; December 6, 1959 – July 11, 2015) was ...

one simply option would be to automatically change it to a semicolon whenever |lead=yes is passed. Juwan (talk) 16:47, 6 December 2024 (UTC)

I am here to request the same thing: on the Nintendo Switch 2 page, the intro ought to have a semicolon in this template after the Hepburn field:

Japanese: ニンテンドースイッチ2, Hepburn: Nintendō Suitchi Tsū, Nintendo branded the console in Japan using its English name.

Brad (talk) 20:37, 7 June 2025 (UTC)

taking a peek at the code, this would be done by modifying the formatting table, as shown below:

local formatting = {
    -- <5p4n> and </5p4n>: place holders for font-weight style spans; akin to stripmarkers, replaced  before function returns
	{'<5p4n>(%s)', {extra}}, 												-- 1 - (extra)
	{'%s<5p4n>', {romanized}},												-- 2 - romanized
	{'%s<5p4n> (%s)', {romanized, extra}},									-- 3 - romanized (extra)
	{'<5p4n>(%s)', {native}},												-- 4 - native
	{'<5p4n>(%s, %s)', {native, extra}},									-- 5 - (native, extra)
	{'%s<5p4n> (%s)', {romanized, native}},									-- 6 - romanized (native)
	{'%s<5p4n> (%s, %s)', {romanized, native, extra}},						-- 7 - romanized (native, extra)
	{'%s<5p4n>', {english}},												-- 8 - english
	{'%s<5p4n> (%s)', {english, extra}},									-- 9 - english (extra)
	{'%s<5p4n> (%s)', {english, romanized}},								-- 10 - english (romanized)
	{'%s<5p4n> (%s, %s)', {english, romanized, extra}},						-- 11 - english (romanized, extra)
	{'%s<5p4n> (%s)', {english, native}},									-- 12 - english (native)
	{'%s<5p4n> (%s, %s)', {english, native, extra}},						-- 13 - english (native, extra)
	{'%s<5p4n> (%s, %s)', {english, native, romanized}},					-- 14 - english (native, romanized)
	{'%s<5p4n> (%s, %s, %s)', {english, native, romanized, extra}},			-- 15 - english (native, romanized, extra)
}

to the code below:

local formatting = {
    -- <5p4n> and </5p4n>: place holders for font-weight style spans; akin to stripmarkers, replaced  before function returns
	{'<5p4n>(%s)', {extra}}, 												-- 1 - (extra)
	{'%s<5p4n>', {romanized}},												-- 2 - romanized
	{'%s<5p4n> (%s)', {romanized, extra}},									-- 3 - romanized (extra)
	{'<5p4n>(%s)', {native}},												-- 4 - native
	{'<5p4n>(%s; %s)', {native, extra}},									-- 5 - (native, extra)
	{'%s<5p4n> (%s)', {romanized, native}},									-- 6 - romanized (native)
	{'%s<5p4n> (%s; %s)', {romanized, native, extra}},						-- 7 - romanized (native, extra)
	{'%s<5p4n>', {english}},												-- 8 - english
	{'%s<5p4n> (%s)', {english, extra}},									-- 9 - english (extra)
	{'%s<5p4n> (%s)', {english, romanized}},								-- 10 - english (romanized)
	{'%s<5p4n> (%s; %s)', {english, romanized, extra}},						-- 11 - english (romanized, extra)
	{'%s<5p4n> (%s)', {english, native}},									-- 12 - english (native)
	{'%s<5p4n> (%s; %s)', {english, native, extra}},						-- 13 - english (native, extra)
	{'%s<5p4n> (%s; %s)', {english, native, romanized}},					-- 14 - english (native, romanized)
	{'%s<5p4n> (%s, %s; %s)', {english, native, romanized, extra}},			-- 15 - english (native, romanized, extra)
}

Juwan (talk) 02:03, 2 January 2025 (UTC)

pinging @Trappist the monk as basically the sole contributor to this template after forking Juwan (talk) 02:04, 2 January 2025 (UTC)

Have you sandboxed this? There are four tables like the one above; if we are to change one, ought we not change the others? Each of the supported templates has its own ~/testcases.

—Trappist the monk (talk) 14:52, 2 January 2025 (UTC)

I haven't, thank you for reminding me of that. Juwan (talk) 15:37, 2 January 2025 (UTC)

@Trappist the monk sandboxed at Module:Nihongo/sandbox. Juwan (talk) 06:54, 6 January 2025 (UTC)

Please do not change established coding style.

You haven't finished – unless {{nihongo}} and {{nihongo krt}} should not use semicolon separators. If they are different for a reason, that reason must be documented.

Update the inline comments to match the new punctuation.

—Trappist the monk (talk) 12:58, 6 January 2025 (UTC)

Hi Brad, I see you reopened this request on 7 June. Is there any update? As far as I see, Juwan unfortunately "pulled out" before addressing Trappist the monk's notes. Would you like to complete the work? I'd do that myself, but per previous discussion it's not clear whether all occurrences should use semicolon separators or not. Est. 2021 (talk · contribs) 02:59, 10 June 2025 (UTC)

it's not clear whether all occurrences should use semicolon separators or not. If that is a true statement then it appears that there is no consensus for this change so I have disabled the edit request.

—Trappist the monk (talk) 13:03, 10 June 2025 (UTC)

I'm not asking for a change, I'm asking for an option between a comma and a semicolon. Right now the template does not fully comply with WP:MOS. -- Brad (talk) 19:36, 10 June 2025 (UTC)

I'm not asking for a change, I'm asking for an option between a comma and a semicolon. Isn't the addition of a separator selector switch a change to the template/module code?

Right now the template does not fully comply with WP:MOS. The en.wiki manual of style encompasses some 160 pages. With which of those pages does this template fail to comply?

—Trappist the monk (talk) 23:21, 10 June 2025 (UTC)

An optional way to replace the comma with a semicolon would result in no changes to existing templates.

As noted above, from Nintendo Switch 2:

Japanese: ニンテンドースイッチ2, Hepburn: Nintendō Suitchi Tsū, Nintendo branded the console in Japan using its English name.

Right now the text after the Hepburn romanization is separated by a comma, which should be a semicolon in this case (and all others that come to mind; anything not in the format Language: Text should be separated by a semicolon). See MOS:SEMICOLON and Comma splice. -- Brad (talk) 01:31, 11 June 2025 (UTC)

@Brad: I finally took time to delve into this issue and update Module:Nihongo/sandbox myself. Please check the resulting templates ({{Nihongo/sandbox}}, {{Nihongo3/sandbox}}, {{Nihongo krt/sandbox}}, {{Nihongo foot/sandbox}}) and let me know if that's ok. Est. 2021 (talk · contribs) 11:01, 18 June 2025 (UTC)

@Est. 2021 Awesome, thanks so much! I quickly tested these out and they look good to me. This is exactly what I had in mind. -- Brad (talk) 23:21, 18 June 2025 (UTC)

@Juwan and Brad:  Completed. Est. 2021 (talk · contribs) 00:11, 19 June 2025 (UTC)

@Est. 2021 thank you very much! Juwan (talk) 16:58, 19 June 2025 (UTC)

If I'm understanding this correctly, instead of adding an option, you changed the commas to semicolons, is that correct? That's not what was requested, no?

Now the punctuation is incorrect on Okinawa Prefecture before the pronunciation:

Okinawa Prefecture (Japanese: 沖縄県, Hepburn: Okinawa-ken; pronounced [o.kʲi.na.wa(ꜜ.keɴ)])

For another example, we would have the same issue with a gloss:

Hito (人, hito; 'person')

Actually, glosses don't even need a preceding comma, neither does a pronunciation without a label, e.g.

Okinawa Prefecture (沖縄県, Okinawa-ken; [o.kʲi.na.wa(ꜜ.keɴ)])

So I think it would be best to make a |sep= parameter that can take the separator itself, i.e. null in this case:

{{Nihongo|Hito|人||{{gloss|person}}|sep=}}

which would render as:

Hito (人 hito 'person')

— W.andrea (talk) 14:28, 26 September 2025 (UTC)

.tag in config of Module:Nihongo

I don't understand the reason for additional indirection for tag = 'ja' four times in the config. Presumably, it must always be exactly 'ja' for Module:Nihongo (see Module:Lang/data). I think it can be dropped: Special:Diff/1286458483/1286504678. For more clarity, a named string constant can be used instead of a literal: Special:Diff/1286458483/1286504838.

If we are to leave this additional indirection through cfg, then I propose using it more consistently: Special:Diff/1286458483/1286459081. —⁠andrybak (talk) 09:12, 20 April 2025 (UTC)

I've read through module's history more carefully and found where tag in cfg came from. The module used to also support templates for Chinese until Special:Diff/1245874224. —⁠andrybak (talk) 09:15, 20 April 2025 (UTC)

Yeah, because of {{hanyu}}. In reality, all of cfg, err_cat, and err_msg tables can be replaced with simpler code. None of those tables are required any longer and the cfg tables are mostly redundant to each other.

But the module works as-is, so I set it aside until some sort of significant change to the module was needed.

Using explicit ja language tags in the code seems to me to be best because this template/module is ja-specific. As for the other data in the tables, those should be kept more-or-less where they are so that users of the module on other-language wikis only have to translate those strings in a single place.

—Trappist the monk (talk) 12:55, 20 April 2025 (UTC)

Footnote option

Would it be reasonable to add an option to display the Japanese text in a footnote? I’m thinking as another option like |lead=footnote. This would be good for lead sentences that are overburdened by the lengthy parenthetical, like at Kyoto Animation arson attack. — HTGS (talk) 21:35, 19 October 2025 (UTC)

{{nihongo foot}}?

—Trappist the monk (talk) 21:40, 19 October 2025 (UTC)

Thank you! — HTGS (talk) 21:53, 19 October 2025 (UTC)

Incorrect ipa

The character ひ is using incorrect ipa ç in place of h. Please look into the matter.

Thanks Siddhu Talreja (talk) 08:46, 24 October 2025 (UTC)

{{Nihongo}} has nothing to do with IPA. While IPA information may be placed in either of the |extra= and |extra2= parameters, this template does nothing with those parameters except to display whatever is given in them. If you are finding an improper phonetic notation for a particular character, you must raise the issue at the article's talk page; {{Nihongo}} is not the source of your issue.

If you wish to raise an issue about something somewhere in the vastness of en.wiki, always report where and under what conditions others may see the issue; be precise.

—Trappist the monk (talk) 11:53, 24 October 2025 (UTC)

Thanks for guiding. Sorry for the inconvenience Siddhu Talreja (talk) 17:44, 24 October 2025 (UTC)

Proposing new optional parameter to suppress label links when lead=yes

{{Lang-zh}} has an optional parameter links=no to suppress links when labels are shown. I propose adding this parameter also to {{Nihongo}} to suppress links on the labels generated by its optional parameter lead=yes; it should be ignored if lead=no or omitted altogether. ‐⁠‑🌀⁠SilSinn^AL982100⁠💬 17:05, 1 December 2025 (UTC)

sometimes italicizes stuff

these templates (ie, this one & the other nihongo* templates in `## see also`) as used on List of Japanese typographic symbols cause some really ugly italicization like 「」 or even worse 。. I think this may be because the {{lang}} template is a little overeager with italicizing latin text, so the `italic=unset` parameter should be provided to that template wherever it is used; but I haven't actually looked at anything. rokke (talk) 08:27, 21 February 2026 (UTC)

Yes, this really is bad. Japanese text, actually, in the real world, not the fantasy world of "software standards" cannot be italicised; there is no such thing as an italic あ, for example. But the <i> tag mindlessly slopes things, which it should never be allowed to do. It's also mildly amusing that on this page (List of Japanese typographic symbols) the separate top and bottom halves of a kana repetition sign actually get broken, because the tops and bottoms do not line up. Imaginatorium (talk) 13:03, 21 February 2026 (UTC)

I tried |italic=unset in the sandbox of {{Nihongo2}} and it removed the italics indeed: Template:Nihongo2/testcases. I wonder if it is possible to make template {{lang}} do it automatically, the way it already does with kanji and kana? Can we add CJK Symbols and Punctuation to the detection logic of Module:Lang? —⁠andrybak (talk) 13:16, 21 February 2026 (UTC)

U+300C: LEFT CORNER BRACKET (「) and U+300D: RIGHT CORNER BRACKET (」) are punctuation characters. For the purpose of determining whether the <text> passed to {{lang}} is Latn or not, all punctuation is treated as if it is Latn because for {{lang}} to assert that the given <text> is Latn, all characters in <text> must be Latn or punctuation. This can be demonstrated:

{{lang|ja|!!}} → !!

Because there is nothing else in the <text>, the ambiguous punctuation is presumed to be Latn. If we add text that is not Latn:

{{lang|ja|「書」}} → 「書」

If a fix is to be made to {{nihongo2}}, perhaps the fix should be to use {{langr}} instead of {{lang}}:

{{langr|ja|「」}} → 「」

Alternatively, at List of Japanese typographic symbols, you might replace:

style="font-size: 2em;" | {{nihongo2|「」}}

with:

{{langr|ja|「」|size=2em}} → 「」

—Trappist the monk (talk) 15:39, 21 February 2026 (UTC)

You say: "...the ambiguous punctuation is presumed to be Latn..."; but this is an error. The punctuation is unambiguously not Latin. So at some level or other the definition of "ambiguous punctuation" or "punctuation" needs to be changed. Where is it specified that 「 for example is "possibly latin punctuation"? Imaginatorium (talk) 17:29, 21 February 2026 (UTC)

Module:Lang gets most of its data from Module:Unicode data/scripts. Module:Lang is currently Unicode v16 data so U+300C and U+300D are included at line 494 (U+3008–U+3020) where they are assigned the script Zyyy (it is the same for v17). Zyyy as a script tag originates from ISO 15924 which is used by IANA and by Unicode. In Module:Lang/data/iana scripts at line 225, IANA includes Zyyy as 'Code for undetermined script'; see the IANA language-subtag-registry file. At Unicode, Zyyy is mapped to the alias 'Common' at https://www.unicode.org/Public/16.0.0/ucd/PropertyValueAliases.txt and at https://unicode.org/iso15924/iso15924-codes.html. At https://www.unicode.org/Public/16.0.0/ucd/Scripts.txt, U+300C and U+300D are defined as:

300C          ; Common # Ps       LEFT CORNER BRACKET
300D          ; Common # Pe       RIGHT CORNER BRACKET

The comment (#et seq.) categorizes U+300C as Ps (opening punctuation of a pair) and U+300D as Pe (closing punctuation); see Table 12. General_Category Values at Unicode. This is no different from U+201C: LEFT DOUBLE QUOTATION MARK (“) and U+201D: RIGHT DOUBLE QUOTATION MARK (”); both of which I regularly find in Japanese text in en.wiki articles (usually in cs1|2 |title= parameters because that is where I spend most of my gnoming time).

Module:Lang treats characters of unknown script (Zyyy) as Latn because that is all that it knows about the character. While my description above indicates that U+300C and U+300D are punctuation characters, Module:Lang does not know that they are punctuation characters so defaults to rendering a string of Zyyy punctuation characters as if it were Latn script (italic) – any non-Latn character will cause Module:Lang to render all of the characters in an upright style. There are workarounds that have been described above.

—Trappist the monk (talk) 23:40, 21 February 2026 (UTC)