Template talk:Nihongo/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

extra parameter disabled?

Someone has disabled extra= (although extra2= still displays).

I noticed the case of

{{nihongo|'''Yamaguchi Hitomi'''|山口 瞳||extra=November 3, 1923 – August 30, 1995}}

rendering as

"Yamaguchi Hitomi (山口 瞳)

without the dates of birth/death. Was this due to Trappist the monk who made a recent change, or does it dater earlier?--Kiyoweap (talk) 10:18, 29 December 2019 (UTC)

Yeah, me. Fixed, I think:

{{nihongo|'''Yamaguchi Hitomi'''|山口 瞳||extra=November 3, 1923 – August 30, 1995}} → Yamaguchi Hitomi (山口 瞳, November 3, 1923 – August 30, 1995)

—Trappist the monk (talk) 11:55, 29 December 2019 (UTC)

Feature request: ruby text

It would be nice to have the kanji with a hiragana ruby text (furigana), or Chinese characters with a bopomofo ruby text, especially for obsolete/historical characters and other standard uses, many very applicable to an encyclopedia. HLHJ (talk) 06:21, 19 February 2020 (UTC)

Works:

{{nihongo|''subete''|{{Ruby-ja|全|すべ}}て||extra=translation: all, everything}} → subete (全（すべ）て, translation: all, everything)

I shall be using this. Thanks to User:Opencooper for the suggestion! HLHJ (talk) 01:27, 22 February 2020 (UTC)

I would note that the first positional parameter is for English (see the template's documentation) and that 'subete' is not English so perhaps the more correct for of your example template is:

{{nihongo||{{Ruby-ja|全|すべ}}て|subete|extra=translation: all, everything}} → subete (全（すべ）て, translation: all, everything)

Visually, the two appear to have the same rendering but under the hood, they are quite different; yours first:

• ''subete''<span style="font-weight: normal"> (<span title="Japanese-language text"><span lang="ja">'"`UNIQ--templatestyles-0000000B-QINU`"'<ruby lang="ja">全<rp>（</rp><rt>すべ</rt><rp>）</rp></ruby>て</span></span>, translation: all, everything)</span>
• <span title="Hepburn transliteration"><i lang="ja-Latn">subete</i></span><span style="font-weight: normal"> (<span title="Japanese-language text"><span lang="ja">'"`UNIQ--templatestyles-0000000D-QINU`"'<ruby lang="ja">全<rp>（</rp><rt>すべ</rt><rp>）</rp></ruby>て</span></span>, translation: all, everything)</span>

—Trappist the monk (talk) 01:38, 22 February 2020 (UTC)

Thanks, Trappist the monk! I've editing Shōji, so it may sometimes be a bit of a judgement call as to which to use, but it's a useful distinction. HLHJ (talk) 23:29, 22 February 2020 (UTC)

Comment: The use of Ruby has been discussed before (sorry, please look in the archives if interested), and the consensus was that it should be avoided except in very special cases. One fundamental reason is that it is incompatible with English typesetting. Japanese characters are already the 'wrong' shape; they need to be about 1.5 times the height of Roman letters to be on the right scale, and adding even more height is unwieldy. And anyway so-called "Ruby" text is simply not an orthographical convention of English, and therefore does not belong. Imaginatorium (talk) 06:59, 23 June 2020 (UTC)

Display of "Hepburn"

Notified: WP:JAPAN, WP:ANIME. — Goszei (talk) 22:53, 17 May 2020 (UTC)

... the real problem is wasting so much space and attention on the link to Hepburn in the first place. It's our only default romanization and should just be given after the characters in italics with no link at all: Bob (Japanese: 漢字, Bōbu). Another more elegant solution is used in Russian articles: use a small-text letter with a link for the curious: Bob (Japanese: 漢字, h Bōbu). — LlywelynII 04:22, 12 September 2019 (UTC)

I read this comment from @LlywelynII: above, and I wanted to start a discussion about it. I agree with him that the link to Hepburn in lead=yes is too prominent. I see a few potential options (I am showing off proposals for lead=no and lead=yes here):
① Status quo, no changes.

Bob (漢字, Bōbu) and Bob (Japanese: 漢字, Hepburn: Bōbu)

② Change lead=yes as proposed by Llywelyn.

Bob (漢字, Bōbu) and Bob (Japanese: 漢字, Bōbu)

③ Change lead=yes and add a third option, i.e. lead=hepburn.

Bob (漢字, Bōbu) and Bob (Japanese: 漢字, Bōbu) and Bob (Japanese: 漢字, Hepburn: Bōbu)

④ Maintain lead=yes and add a third option, i.e. lead=nohepburn.

Bob (漢字, Bōbu) and Bob (Japanese: 漢字, Hepburn: Bōbu) and Bob (Japanese: 漢字, Bōbu)

⑤ Adopt the alternate linking style proposed by Llywelyn, or add a third option for it like ③ or ④.

Bob (漢字, Bōbu) and Bob (Japanese: 漢字, h Bōbu)

Personally, I favor ③ for reasons of simplicity, consistency with other major language templates, and reducing existing lead clutter without having to make mass edits. Unlike Chinese-related articles that often need to display several romanization styles due to varying dialects pronouncing the same characters (see Template:Lang-zh: Cantonese Jyutping, Hokkien Pe̍h-ōe-jī, Bopomofo, etc.), we use Modified Hepburn in all cases, as prescribed by MOS:JAPAN. Opinions? — Goszei (talk) 02:52, 14 May 2020 (UTC)

Option 3 would be my favourite, though I'd also be fine with 2. bamse (talk) 08:33, 15 May 2020 (UTC)

I prefer Option 3, it's modular and decent. «ias!|,,.|^usbk» 11:52, 21 May 2020 (UTC)

Sorry, but I can make no sense of this at all. Who is "Bob"? What is the example supposed to show? Even in real examples, it is often not clear what the relationship between the bits is, since people insist on assuming that if we say "English", or "Kanji", or "Japanese" or "Romaji" it is just obvious what these are. I just came across a good example where the lean mean version (no "Hepburn" for example, which I generally favour) is somehow not very clear: Densha de GO! (電車でGO!, "Go By Train"). This surely needs a "lit." or similar. Imaginatorium (talk) 04:33, 22 May 2020 (UTC)

@Imaginatorium: "Bob" is simply an arbitrary example to show off my proposed changes to the template. In your example, there is no need for a Hepburn trasnscription because the common English title for the subject is the transcription. There are however some examples that require all four fields: English name (kanji, transcrption, lit. "translation"). My proposed changes above only concern the linking of "Hepburn", do you have an opinion on this topic? — Goszei (talk) 08:18, 22 May 2020 (UTC)

Firstly, I think it really helps to use plausible examples. This one is so artificial ("meaningless", "wrong", whatever) it hurts to look at it. And your comment on my (not particularly good) article is not strictly true: the hepburn romanisation would be densha de gō. But anyway, in general I think writing "Hepburn" does not help the general reader, particularly since there is only one system is general wide use, and WP always uses this. However, I also think that there may well be cases in which something else is applicable: looking at "Bob", I can't even say "Well, it's obviously OK in this case", because this isn't a case. Imaginatorium (talk) 15:02, 22 May 2020 (UTC)

I see nothing wrong with the current format. It's important to have some kind of link to Hepburn romanization, otherwise how is a reader supposed to figure out what the text represents? Linking only to Japanese language will not help them there.

In Russian, Wikipedia uses its own system which doesn't correspond exactly to any other standard system; while I think they should link to that page or a similar one explaining exactly how it's romanized, they simply link to Romanization of Russian, which is okay. However, for Japanese we use exactly modified Hepburn, with no further changes, thus calling it "Hepburn" and linking to that article is the most useful for readers, telling them exactly how it was romanized and providing them the information they need to understand it. --Bigpeteb (talk) 19:54, 29 May 2020 (UTC)

@Goszei: As someone who uses these templates a lot as of late, my preference is ③. Psiĥedelisto (talk • contribs) ^{please always ping!} 03:20, 22 June 2020 (UTC)

Discussion at WT:JAPAN#On the italicization of foreign-language song titles

 You are invited to join the discussion at WT:JAPAN#On the italicization of foreign-language song titles. Psiĥedelisto (talk • contribs) 01:07, 28 May 2020 (UTC)

Revising my "Hepburn" display proposal

Notified: WP:JAPAN, WP:ANIME, Wikipedia talk:Manual of Style/Japan-related articles — Goszei (talk) 05:55, 22 June 2020 (UTC)

This is a (hopefully more clear) restatement of my proposal above. Pinging for comment @Psiĥedelisto @LlywelynII, Bamse, I'm Aya Syameimaru!, Imaginatorium, and Bigpeteb:
Please post which new proposal that you support, as I want to build consensus around this new formulation (for those who commented on my old post: the old Proposal ③ is the same as new Proposal ①). Please scroll down and also consider Imaginatorium's proposal, for which I have made a second table. — Goszei (talk) 00:39, 24 June 2020 (UTC)

	default, with no parameters	with lead=yes parameter	with a new parameter (i.e. lead=hepburn/nohepburn)
Current	One Piece (ワンピース, Wan Pīsu)	One Piece (Japanese: ワンピース, Hepburn: Wan Pīsu)
Proposal ①	One Piece (ワンピース, Wan Pīsu)	One Piece (Japanese: ワンピース, Wan Pīsu)	One Piece (Japanese: ワンピース, Hepburn: Wan Pīsu)
Proposal ②	One Piece (ワンピース, Wan Pīsu)	One Piece (Japanese: ワンピース, Hepburn: Wan Pīsu)	One Piece (Japanese: ワンピース, Wan Pīsu)
Proposal ③	One Piece (ワンピース, Wan Pīsu)	One Piece (Japanese: ワンピース, h Wan Pīsu)

Justification: I think that there should be a way to hide the display of "Hepburn" when the lead=yes parameter is used. For a vast majority of readers, I think that it is evident that what is displayed after the Japanese text is a rendering of the text in Latin characters, and that the particular variety of romanization is not very relevant. Linking to the article for Hepburn romanization in every lead only serves as a distraction from the subject of the lead sentence. Even for readers who are interested in the method used, having a link to Hepburn re-appear in the lead of every article is not helpful. WP:ROMAJI states: People who care about other romanization systems are knowledgeable enough to look after themselves. I believe a similar principle applies here: those who are particularly interested in romanization can research the various systems for Japanese, but our goal in the lead sentences for articles about unrelated topics is to give a fair indication of pronunciation to the intended audience of English speakers.

I primarily edit WP:ANIME-related articles, where the lead=yes parameter is in widespread use. I support Proposal ① (shifting my support to Imaginatorium's proposal, see below), because it would immediately REMOVE the display of "Hepburn" from the articles that use it, while retaining the functionality if needed by adding a new parameter (I suggest lead=hepburn). Proposal ② is similar, except that it would KEEP the display of "Hepburn" for all the articles that currently use lead=yes, and add an "opt-out method" with a new parameter (I suggest lead=nohepburn). Proposal ③ is a sort of "compromise"; it keeps a link to Hepburn romanization, but minimized to limit distraction; the display specifics would be another matter of discussion (h Wan Pīsu or H Wan Pīsu or Wan Pīsu^?, etc.) I'm interested in hearing your opinions. — Goszei (talk) 03:05, 22 June 2020 (UTC)

Comments

@Goszei: As far as I can tell, new proposal ① is equal to old proposal ③. So I support ①. I didn't find your example difficult to understand, maybe because, as a programmer, foo, bar, and baz do not phase me. Psiĥedelisto (talk • contribs) ^{please always ping!} 03:57, 22 June 2020 (UTC)

Oh, and by the way Goszei, I don't get why you just don't wrap it in a {{transl}}, as in, {{transl|ja|Hepburn|Wan Pīsu}} (Wan Pīsu). This way, "Hepburn transliteration" is shown on hover. Psiĥedelisto (talk • contribs) ^{please always ping!} 04:03, 22 June 2020 (UTC)

@Psiĥedelisto: That's a good point: the Nihongo template currently uses the {{transl}} wrapper, and I've updated my proposals above to use it as well. — Goszei (talk) 04:26, 22 June 2020 (UTC)

This proposal looks clearer now. ias!@,,.yy 04:16, 22 June 2020 (UTC)

I'm supporting Proposal 1, a good compromise. ias!@,,.yy 04:44, 22 June 2020 (UTC)

@Goszei: I think you missed an important word when you quoted WP:ROMAJI, which I'll highlight: People who care about other romanization systems are knowledgeable enough to look after themselves. I would agree with that; someone who knows about Nihon-shiki or Kunrei-shiki and for some reason wants to know how to romanize the Japanese text in those can use the appropriate articles and figure it out on their own.

However, for the average reader, we have no idea how they got to any particular article, and we have no idea if they know anything about the Japanese language. We don't know if they speak English fluently. (Keep in mind, Hepburn is made to be intuitive to speakers of English, not necessarily other languages, however a lot of people on the Internet read English Wikipedia rather than one in a language they know better because it's more complete.) We don't know how they might try to pronounce foreign words; British speakers in particular are likely to read Fuji-san and pronounce it to rhyme with "hat" or "pan". The only way to teach them the correct way to pronounce it is to link to a page which provides that explanation. That's the whole point of having a lead=yes parameter. Removing the text and the link to Hepburn romanization is counterproductive.

You wrote two particular sentences that explain your reasoning, which I fundamentally disagree with:

"Linking to the article for Hepburn romanization in every lead only serves as a distraction from the subject of the lead sentence." No, it serves to inform the reader of how the text was romanized and provide them the information they need to utilize that romanization in order to pronounce the text correctly. What may be a distraction for you is essential for others. Your desire to hide or remove that information should not trump their need to see it.

"Even for readers who are interested in the method used, having a link to Hepburn re-appear in the lead of every article is not helpful." But you can't know if it's "re-appearing" for any particular reader! Someone reading the article may never have read anything about Japan, and may know nothing about Japanese language and romanization! It could be a kid learning about their favorite anime, or learning how to use an encyclopedia to do research for a report. The point is, you don't know, and you have no basis for asserting that someone who reads a given article on something related to Japanese will have any idea what the romanized text represents or how to pronounce it, yet you want to remove the link that would directly explain it to them.

To quote wholesale from WP:AUDIENCE:

Wikipedia is an international encyclopedia. People who read Wikipedia have different backgrounds, education and opinions. Make your article accessible and understandable for as many readers as possible. Assume readers are reading the article to learn. It is possible that the reader knows nothing about the subject, so the article needs to explain the subject fully.

Thus, I still oppose making this change. Your complaint seems to be based on some minor aesthetics ("It's so annoying that I read lots of articles on Japanese articles and keep seeing the same link that I don't need") rather than on what's appropriate for an encyclopedia and what's helpful or usable for the general reader. Yes, sometimes the lead sentence of an article does get cluttered with information in parentheses. However, there are a lot of considerations in writing a lead—look at how long MOS:LEAD is, not to mention all the related pages it links to—and omitting useful definitions to shorten the sentence or parenthetical by one word is not among them. --Bigpeteb (talk) 17:27, 22 June 2020 (UTC)

@Bigpeteb: In response to your quote from WP:AUDIENCE: I don't agree that omitting the display by default would significantly hurt understandability. Providing information in an accessible way is our #1 goal on Wikipedia, but "accessibility" includes controlling how and when that information is displayed. I think this particular inclusion does not serve this purpose well. A "kid learning about their favorite anime" does not need to know, and likely does not care, that Hepburn is the specific romanization that we use; all they really need is the fair indication of the pronunciation that it provides to the to the intended audience of English speakers. The purpose of romanization is to serve these narrow purposes, which are fulfilled by simply writing the transcription. Readers who care and "dig deeper" (which are a small minority) will be able to find out about Hepburn and pronunciation guides at Help:Japanese (which is very helpful!) or MOS:JAPAN, and don't need to be told a second time.

• I have checked some major non-English Wikipedias to see how they handle this issue, just for context. They use either my Proposal 1 (omit) or a variation on my Proposal 3 (small link using a question mark; and not to Hepburn romanization, but instead to their equivalent of Help:Japanese).

• French Wikipedia: One Piece (ワンピース, Wan Pīsu^?)
• German Wikipedia: One Piece (jap. ONE PIECE（ワンピース）, Wan Pīsu)
• Spanish Wikipedia: One Piece (ワンピース Wan Pīsu^?)
• Italian Wikipedia: One Piece (ONE PIECE - ワンピース Wan Pīsu^?)

As a side note, MOS:LEADLANG shows off this as an example of a foreign-language lead: Chernivtsi Oblast (Ukrainian: Чернівецька область, Chernivets’ka oblast’). This omits the information about the "Ukrainian National System" used on Wikipedia, which is instead placed at WP:UKR. As a reader, it would not be helpful to me to display something like Chernivtsi Oblast (Ukrainian: Чернівецька область, UNS: Chernivets’ka oblast’) in every lead. All that I really care about is a fair indication of the Ukraininan pronunciation, which it provides me. At most, (Ukrainian: Чернівецька область, Chernivets’ka oblast’ ^?) would give the information about the specific type of Ukrainian romanization its due weight, in my opinion. — Goszei (talk) 22:58, 22 June 2020 (UTC)

I continue to disagree with some of your points.

Linking to Help:Japanese would be helpful, except that this template doesn't do so, and you're not proposing that it should do so. You can't argue that readers can find the information they would need there when we do nothing do help them get there. How would they know to look there? How would they find that page if we don't tell them where it is? Really, if we expect readers will find it by searching, then why do we bother hyperlinking articles at all?

MOS:JAPAN is an article for editors. It's not appropriate to direct readers there.

Again, you cannot argue that readers "don't need to be told a second time". Every article could be somebody's first. That's why it's important to link to background information they might need and not already have. The only thing you can argue by saying they "don't need to be told a second time" is that lead=yes should not be used more than once per page, which has always been the rule and which I don't think any of us are suggesting changing.

You make an interesting comparison with the non-English WPs. But AFAIK, there's no rule or guideline that various language WPs should use similar formatting. English WP broadly abandoned the superscript question mark in most of its templates years ago. I think that was a good decision; it can be hard to spot, and it's too opaque as it doesn't tell you anything unless you hover over it or follow the link. I think it would be particularly bad to use when transliterating a foreign language, because to someone unfamiliar with the transliteration scheme being used, it could look like it's part of the transliteration to someone who isn't familiar with how the text is romanized.

Yes, I saw the MOS example using Ukrainian as well. However, I took it to be informative, not normative. Moreover, I have the same problem with that example as I did with the Russian one from the previous discussion: I think it should link to WP:UKR, and I think it's doing a disservice to the reader by not doing so. And again, you say that "as a reader, it would not be helpful to me to display something like "Chernivtsi Oblast (Ukrainian: Чернівецька область, UNS: Chernivets’ka oblast’)" in every lead", but—again!—I disagree. I think it would be helpful. If you keep repeating the same argument, I'm going to run out of ways to tell you I think you're wrong.

I'll throw you a bone and propose an alternative that hasn't been considered. Looking at pages like Japan or Mount Fuji, I noticed that the pronunciation in IPA directly links to Help:IPA/Japanese. (Again, a welcome change from the bad old days when there would have been an undecipherable question mark or a taunting "what's this?" floating after it.) Why not do the same with the romanization? That would look like:

One Piece (Japanese: ワンピース, Wan Pīsu)

although formatted like that, it would probably be better to link to Help:Japanese than Hepburn romanization. I think that would satisfy both of our desires, and I would tentatively support it, but I wouldn't be surprised if there were some pushback. Unlike IPA (which is put in brackets or slashes) or other foreign languages (which use non-English scripts), there isn't as much to set off the romanized text as special other than it being italicized. I think it would be harder for people to notice that it's also a hyperlink, and it wouldn't be very obvious why it's being linked. It also precludes having part or all of the romanized text link to anything else, although I don't know if any articles do that.

Lastly, after doing a lot of searching to see if this has been discussed before, I think this really ought to move to Wikipedia talk:Manual of Style/Japan-related articles, as far fewer editors are likely to watch a Template page than a MOS page. The archives of the talk page there are enormous, and there are lots of old discussions about how to format text using this template. --Bigpeteb (talk) 00:37, 23 June 2020 (UTC)

Comment: (indenting is all a bit unclear, I think) Anyway, I notice that the real issue is a proposal to increase the number of links in a pronunciation note from one to two, which I tend to oppose. But I understand the wish to let readers, and perhaps particularly to whom Hepburn is not particularly "natural", know about it. I suggest that the link to Japanese language is really superfluous, since readers only need to know that this is in the language of Japanese, not any information which is historical, orthographical, morpho- well any number of pseudogreek adjectives... Somehow the note showing the Japanese writing and Roman equivalent should link to somewhere that explains what the bits are. Perhaps that needs writing, and it would give "Hepburn" as the name of the transliteration, among many other useful and interesting tidbits. Imaginatorium (talk) 07:10, 23 June 2020 (UTC)

	default, with no parameters	with lead=yes parameter
the "Help:Japanese" proposal, per Imaginatorium	One Piece (ワンピース, Wan Pīsu)	One Piece (Japanese: ワンピース, Wan Pīsu)

@Imaginatorium: Is something like Help:Japanese what you have in mind? I agree with you that linking to that page with "Japanese:" would be more even useful for readers than just straight links to Japanese language and Hepburn romanization, as we have been discussing. The hatnote on that page would redirect people who click and are interested in the article about the language itself. I think this is a very elegant solution, and I now support it over all of as an alternative to my proposals. Thoughts, everyone? @Bigpeteb, Psiĥedelisto, and I'm Aya Syameimaru!: — Goszei (talk) 07:46, 23 June 2020 (UTC)

I think it can work. Support. Iias!:postb□xI 07:48, 23 June 2020 (UTC)

Support. A simple change that addresses everyone's problems, and seems to have little or no downside. --Bigpeteb (talk) 21:47, 23 June 2020 (UTC)

I support this as well, but  oppose Bigpeteb's idea of linking the Hepburn, unless a wider RfC is done that all transliterations need to change to do the same. In my view, the idea violates MOS:EASTEREGG/WP:PLA. No other transliterations are, to my knowledge, linked like that, so I would not know what to expect from such a link, or why only articles about Japan have them. And, I don't think new readers would either. Perhaps one would expect a Japanese-language version of the article? An article about rōmaji in general? Psiĥedelisto (talk • contribs) ^{please always ping!} 04:25, 24 June 2020 (UTC)

Error with the = sign

"=" is needed for List of We Never Learn chapters. Chapter 150 is literally called [x]=, and the sign is used in later chapter names, but the template shows error when I try to use it. Smeagol 17 (talk) 05:29, 22 July 2020 (UTC)

Smeagol 17, I think I found a work-around with these revisions. — Goszei (talk) 05:37, 22 July 2020 (UTC)

Thanks, it works, but maybe the tempate should accept those signs as-is. Smeagol 17 (talk) 06:03, 22 July 2020 (UTC)

Smeagol 17, the = sign is the separator between parameter names and parameter values of template parameters. You therefore need to either explicitly number, or use named parameters in order to use = inside a parameter value. Help:Templates#Numbered_parameters, or use something like {{=}} or {{equals}} —TheDJ (talk • contribs) 07:58, 22 July 2020 (UTC)

Thanks, I understand. Smeagol 17 (talk) 08:09, 22 July 2020 (UTC)

Minor bug with preview rendering

I've noticed a small glitch in how MediaWiki Page Previews and this template interact. Two instances of the bug can be seen in the hover preview for this link: Kyoto Animation. If the template call is followed by a comma, there is an extra space rendered in between.

Any ideas on how to fix it? — Goszei (talk) 00:00, 3 December 2020 (UTC)

I'm not convinced that the 'problem' is the fault of this template. Compare the actual text in the first line of Kyoto Animation with the first line of text in the popup:

• Kyoto Animation Co., Ltd. (Japanese: 株式会社京都アニメーション, Hepburn: Kabushiki-gaisha Kyōto Animēshon), often abbreviated KyoAni (京アニ, Kyōani), is ...
• Kyoto Animation Co., Ltd. , often abbreviated KyoAni , is ...

The parenthetical text has been dropped. Each parenthetical is preceded with a space character and followed with a comma. I suspect that the popup doesn't know what to do with the template so it preserves whatever was around it.

—Trappist the monk (talk) 00:35, 3 December 2020 (UTC)

@Trappist the monk: Hm... the "lang-xx" templates and "zh" template render this properly, though; see the popups for French Navy and Shang dynasty. I think the parser is confused by how (unlike those templates) Nihongo also generates the parentheses, instead of just the information inside them.

Maybe this could be fixed by somehow getting the "space" generated inside the template to be ignored by the parser. — Goszei (talk) 01:42, 3 December 2020 (UTC)

Compare the raw markup:

• Kyoto Animation:

  {{Nihongo|'''Kyoto Animation Co., Ltd.'''|株式会社京都アニメーション|Kabushiki-gaisha Kyōto Animēshon|lead=yes}}, often...

• French Navy:

  The '''French Navy''' ({{lang-fr|Marine nationale|lit=National Navy}}), informally "{{lang|fr|La Royale}}", is...

• Shang dynasty:

  The '''Shang dynasty''' ({{zh|c={{linktext|商朝}}|p=Shāngcháo}}), also

The parenthetical is created by {{nihongo}} in Kyoto Animation whereas the parentheses are manually placed in French Navy and Shang dynasty. But, here is an example that exhibits the problem but doesn't use a template:

• USS Benjamin Franklin. The raw markup is:

  '''USS ''Benjamin Franklin'' (SSBN 640)''', the...

The popup removed the parenthetical hull designator but kept the space and the comma. This is more-or-less the same, doesn't have a trailing comma and doesn't exhibit the problem:

• USS Will Rogers (SSBN-659)

  '''USS ''Will Rogers'' (SSBN-659)''' was...

Still not convinced that the problem is with {{nihongo}}; if it were, then Benjamin Franklin wouldn't exhibit the problem...

—Trappist the monk (talk) 02:19, 3 December 2020 (UTC)

"Don't use the 'lead' parameter in biographical articles"?

This seems like a given to me, per this, but is it a given to everyone else? If not, what do folks think of my reasoning? Should we rūru-ka this if we haven't already? Hijiri 88 (聖やや) 20:00, 31 December 2020 (UTC)

Template-protected edit request on 20 March 2021

To add an additional output format order for the template's arguments, I'd like to request merging the code I propose on the page Module:Nihongo krt.

To do such a thing, I have created a template page: Template:Nihongo krt to output in the format: KANJI/KANA (ROMAJI, ENGLISH, EXTRA) EXTRA

Since the syntax is the same as the existing templates for Nihongo and Nihongo3, this provides an additional option for editors to present Japanese text in a consistent way in articles.

Why do we need another format?

Currently the format focuses on "English" first (T:Nihongo) or "Rōmaji" first (T:Nihongo3). However in linguistics pages that analyse the pronunciation and conjugations of Japanese words, we need the kanji/kana to be the main focus within this context (since you cannot differentiate linguistic patterns with rōmaji, as rōmaji doesn't discriminate kanji). So for the context of pronunciation and conjugations, we need an easy template that puts the kanji first with a quick rōmaji pronunciation guide beside it. In many cases for these articles, the semantic meaning of the words isn't relevant either, so we don't need to crowd the text with an English translation for each one.

The code is already working, however it would be more synergous if it were merged into one module rather than having almost identical concurrent modules doing the same thing. JKVeganAbroad (talk) 17:55, 20 March 2021 (UTC)

Why do we need another format? I have no opinion; others may.

The documentation at {{Nihongo krt}} suggests that that template is inconsistent with {{nihongo}}, {{nihongo3}}, and {{nihongo foot}}. That choice seems misguided to me. Editors regularly get the parameter order wrong with these templates so it is, I think, important that all of the nihongo family maintain a consistent parameter order. Since I'm talking about consistency, the template name should probably be {{nihongo krt}} (what does the 't' stand for?)

No testcases? How do we know that the template works as it should?

—Trappist the monk (talk) 18:55, 20 March 2021 (UTC)

Hi Trappist the monk, thank you for reading over this proposal and the code! To address your points:

1. At first I was going to make this its own independent module, but after consideration, I changed my mind during the coding (I came to the same conclusions that you mentioned about editors mixing up parameter ordering). Indeed, the template was re-coded to (yes indeed) be compatible with {{nihongo}}, {{nihongo3}}, and {{nihongo foot}}, with the parameters in the same positions.

I thought I had corrected the documentation to reflect this, but I missed a few sections (it was late at night for me, sorry). I've amended the documentation as such (sorry about the trouble).

2. Since I'm talking about consistency, the template name should probably be {{nihongo krt}} (instead of {{nihongo-krt}})

As for this, I'm not familiar with the existing naming conventions, so I trust and endorse your suggestion. I've already made such changes, and re-pointed the URLs in this discussion towards this new name.

3. what does the 't' stand for? "t" is for "translation". Perhaps it could be "e" for English, but I wanted the template to be multi-lingual friendly for other Wikipedia languages. I'm not sure about the validity of my judgement here.

4. I've created a testcases page, thank you for the advice.

Thank you again for your constructive criticism so far. Do you have any more insights we could build upon?

JKVeganAbroad (talk) 06:51, 21 March 2021 (UTC)

Except for the glaringly obvious, the test cases look like they are correct.

—Trappist the monk (talk) 11:42, 26 March 2021 (UTC)

That's great news. Module:Nihongo krt is a fork from the current version of Module:Nihongo, so assuming nobody objects to this addition, should I go ahead and modify the Module:Nihongo/sandbox to ensure the other testcases (Nihongo testcases, Nihongo3 testcases, Nihongo foot testcases) produce identical results?

JKVeganAbroad (talk) 13:41, 26 March 2021 (UTC)

You could; that is, after all, what sandboxes are for.

I gather that the glaringly obvious to me isn't glaringly obvious to you.

—Trappist the monk (talk) 14:06, 26 March 2021 (UTC)

Indeed, if theres an obvious problem I haven't noticed it. What's the issue?

I'll try to modify the main sandbox later tonight.

JKVeganAbroad (talk) 05:17, 27 March 2021 (UTC)

FOLLOW-UP: Is the obvious thing that the error message is recycled from Nihingo3?

If so, that's because I need help to implement a proper error message, as it seems from the code that error-message handling isn't self-contained within the Module:Nihongo code, and is outsourced to some other script on Wikipedia... I don't know where that is.

JKVeganAbroad (talk) 05:31, 27 March 2021 (UTC)

I fixed the error message; I misread the code at first, but after re-reading it, the error message code wasn't complicated at all. It assumes the same error for all templates, and the only variant is the template title.

Anyway, I've replaced the code in the Module:Nihongo/sandbox and all sandbox testcases (Nihongo testcases, Nihongo3 testcases, Nihongo foot testcases, Nihongo krt testcases) are identical to the live testcases. It seems the code is ready for merging. JKVeganAbroad (talk) 12:00, 27 March 2021 (UTC)

Template-protected edit request on 20 March 2021

To add an additional output format order for the template's arguments, I'd like to request merging the code I propose on the page Module:Nihongo krt.

I have created a template page: {{Nihongo krt}} to output in the format: KANJI/KANA (ROMAJI, TRANSLATION (English), EXTRA) EXTRA

This is like {{Nihongo2}}, except followed by additional information in parenthesis.

(Somebody closed this edit request because "there is not yet a specific request here with consensus", so I assume I have to create this new request now that I've addressed the concerns).

JKVeganAbroad (talk) 01:49, 22 March 2021 (UTC)

Support. It's a good thing that the parameter orders in this new template match the other Nihongo templates. It would be nice if all of the templates could be simplified down to just one that uses an order parameter, but that's a project for another day. — Goszei (talk) 01:45, 23 March 2021 (UTC)

done

—Trappist the monk (talk) 13:01, 27 March 2021 (UTC)

Thank you so much! --JKVeganAbroad (talk) 14:05, 27 March 2021 (UTC)

Template-protected edit request on 30 May 2021 — Kerning issues

The Nihongo module automatically applies italics formatting to rōmaji text. However, in 3 select cases where the rōmaji touches the closing parenthesis bracket, kerning issues emerge. This means the italics letters are rendered such that the final character overlaps with the closing parenthesis character, which can lead to accessibility and reading issues.

Wikipedia recommends using a   character in these situations to correct kerning issues and improve readability. Many editors may not even notice the problem or know how to correct it manually. Furthermore, doing this manually is costly for the page-size on pages that use hundreds of nihongo modules (for example, if this merge proposal were accepted, the Japanese verb conjugation would be reduced by 1400 bytes by eliminating the 200   codes currently in place).

I've proposed an amendment to the Nihongo module code to automatically include a   in the 3 cases where kerning problems are likely to emerge. You can notice the difference in test cases 69 and 70 of nihongo and test case 46 of nihongo krt (nihongo3 and nihongo foot are unaffected by kerning problems).

Since adding the   is invisible, amongst only 3 syntax cases and improves the visibility and accessibility of the formatted output, I doubt this would create objections in the community.

Kind regards, JKVeganAbroad (talk) 15:12, 30 May 2021 (UTC)

On my machine with my browser (chrome current version)   renders roughly the same width as a generic space character so the offset between the trailing italicized character and the closing parenthesis is objectionably wide (especially when italicized character is not bolded); cf:

l) ← ''l'') – no space

l ) ← ''l'') – generic space

l ) ← ''l'') –  

and when bolded:

l) ← '''''l''''') – no space

l ) ← '''''l''''') – generic space

l ) ← '''''l''''') –  

perhaps a better solution is css:

l) ← ''l''<span style="margin-left:.1em">)</span> – css

l) ← '''''l'''''<span style="margin-left:.1em">)</span> – css

—Trappist the monk (talk) 15:43, 30 May 2021 (UTC)

I've been using Firefox, but I couldn't replicate the problem on Chrome or other browsers on my machine. I'm running macOS, so it might be a rendering issue with the code on Chrome for Windows or Linux, or some other sort of interference.

But regardless, I really like your solution for two reasons:

1) Presumably it resolves the issue on your machine, and therefore other people's machines too, and

2) It doesn't add an extra annoying space character if people try to copy and paste the romaji, thus it doesn't introduce character interference.

I implemented your suggestion in the sandbox, and the test-cases render perfectly across my browsers and devices (thank you!). Does it render okay on your end?

— JKVeganAbroad (talk) 00:53, 31 May 2021 (UTC)

 Implemented — Martin (MSGJ · talk) 11:11, 7 June 2021 (UTC)

You're a legend, thank you! — JKVeganAbroad (talk) 12:12, 7 June 2021 (UTC)

Fix the "Hepburn" linked page in Bengali Template.

The word "Hepburn" in nihongo template redirects to "Hepburn romanization" wiki page. But word "হেপবার্ন" (hepburn) in Bengali Template doesn't redirects to the actual bangla wiki page of Hepburn "হেপবার্ন রোমান লিপি", like the en template; rather it promotes to Create a whole page because it doesn't exists.

Now, I can create a page in this "হেপবার্ন" name and redirect it to the actual one; but fixing it in the core would better I think. Every bangla wiki pages that used this "nihongo" template the Hepburn(হেপবার্ন) word is in RED, even though it exists. And probably this occurrence is from the start of this template. Yet, isn't gotten fixed.

Anybody in charge of this template or with authority, kindly can you fix this problem? Word "হেপবার্ন" should get linked to the wiki page named "হেপবার্ন রোমান লিপি".

Thank you for reading. লাবিব আহমদ (talk) 06:07, 11 June 2021 (UTC)

This is about bn:টেমপ্লেট:Nihongo? That template isn't protected so you should be able to change [[Hepburn romanization|হেপবার্ন]] to [[হেপবার্ন রোমান লিপি|হেপবার্ন]] yourself.

—Trappist the monk (talk) 11:54, 11 June 2021 (UTC)

Template-protected edit request on 7 June 2021 — Kerning issues

This is awkward. Basically for the same reasons as the edit request above, I propose this amendment to the Nihongo module code to automatically use CSS via including <span style="margin-right:.1em">(</span> to avoid 6 fringe cases where the italics formatting of rōmaji text causes kerning issues. Specifically, these are visible in test cases 69 and 73 of nihongo and test cases 44, 46, 47 and 48 of nihongo krt (nihongo3 and nihongo foot are unaffected by kerning problems). Notice how the letter "j" touches the first opening parenthesis bracket. The letters "y" and "p" are also affected in this way. The goal is to improve the visibility and accessibility of the formatted output. Kind regards, JKVeganAbroad (talk) 13:13, 7 June 2021 (UTC)

I wondered this at the time of the other edit request but didn't voice it. Would it not be better to apply this kerning only when it is needed rather than always regardless of need? So only kern those initial lowercase letters that have a descender [jpy] that touches the parenthesis and those final uppercase or lowercase letters with an ascender that touche the parenthesis [dfklt] [EFHIJKMNTUVWXYZ].

lowercase with descenders:

• (g – doesn't need kerning
• (j
• (p
• (q – doesn't need kerning
• (y

lowercase with ascenders:

• b) – doesn't need kerning
• d)
• f)
• h) – doesn't need kerning
• i)
• j)
• k)
• l)
• t)

lowercase without ascenders or descenders:

• a) – doesn't need kerning
• c) – doesn't need kerning
• e) – doesn't need kerning
• m) – doesn't need kerning
• n) – doesn't need kerning
• o) – doesn't need kerning
• r)
• s) – doesn't need kerning
• u) – doesn't need kerning
• v)
• w)
• x)
• z)

uppercase:

• A) – doesn't need kerning
• B) – doesn't need kerning
• C) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
• D) – doesn't need kerning
• E)
• F)
• G) – doesn't need kerning
• H)
• I)
• J)
• K)
• L) – doesn't need kerning
• M)
• N)
• O) – doesn't need kerning
• P) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
• Q) – doesn't need kerning
• R) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
• S) – doesn't need kerning – needs kerning on my system (JKVeganAbroad)
• T)
• U)
• V)
• W)
• X)
• Y)
• Z)

punctuation:

• ')
• ")
• ?)
• !)
• ])
• )) – doesn't need kerning

—Trappist the monk (talk) 13:56, 7 June 2021 (UTC)

…Would it not be better to apply this kerning only when it is needed rather than always regardless of need?…

Hey yeah, you're right of course. First and foremost, it's kind of a bother to learn a new programming language, so this was the most efficient "solution" I could come up with (i.e. the lazy "Well, if it works…" solution). Secondly, to be honest, I'm not exactly keen to research how to do it. Even if I could implement some sort of substitution via simple RegEx, I don't really understand or know how to work with variables in the Lua language (I mean, all the variables are %s (wtf?!) Why aren't they unique? Hahaha omg plz halp). So basically my own shortcomings are the reason I proposed this workaround. EDIT: I don't think it's terrible though, I doubt anyone would notice (also since even with this solution I think the added gap is just the tiniest bit too small for comfort, but at least there's technically no overlap).

Would you be able to help me?

By the way, I added some "test cases" to the list you provided, and added some disagreements where my system (macOS, Firefox, latest) presents kerning overlapping.

Cheers — JKVeganAbroad (talk) 14:33, 7 June 2021 (UTC)

Hold on just a second.

I've just doubled the gap from .1em to .2em, and it looks marvelous. So much better for the opening and closing parenthesis brackets.

BUT doubling the gap, which properly solves the problem, creates the exact problem you implicitly anticipated: The gap is noticeably too large in the cases where characters don't need it: see the test cases 3, 7, 25, 29, 49 and 53 of nihongo and test cases 5, 6, 7, 15, 16, 17, 25, 26, 27, 36, 37 and 38 of nihongo krt.

The solution you proposed—only when required—is the solution we need. Could you please lend your expertise, if you can?

— JKVeganAbroad (talk) 15:09, 7 June 2021 (UTC)

To do that I'm going to remove the current kerning from the sandbox. I will also set this edit request to answered to prevent an inadvertent update to the live module. If we don't find a reasonable solution, we can restore the sandbox.

—Trappist the monk (talk) 15:31, 7 June 2021 (UTC)

Yes, good idea. — JKVeganAbroad (talk) 15:41, 7 June 2021 (UTC)

@Trappist the monk, the function you've added to the sandbox works really well in the test cases (nihongo, nihongo krt). The moment I read this code was the moment I knew you are Neo and can read the Matrix! I can't thank you enough for your coding.

I vote yes to merging your proposal. — JKVeganAbroad (talk) 02:37, 8 June 2021 (UTC)

done.

—Trappist the monk (talk) 12:43, 8 June 2021 (UTC)

Thank you, my hero! — JKVeganAbroad (talk) 12:50, 8 June 2021 (UTC)

Feedback: I think the space is way too much for the cases that don't need kerning, as marked by Trappist above, (this is a bug, see below) and still a little too much for the cases that do need kerning. On my browser at least, it looked like an errant space, which I tried to remove. — Goszei (talk) 01:46, 10 June 2021 (UTC)

Oh, I see the problem. At Hololive Production#History there is spacing applied at the end of "Kabushiki-gaisha" because it is wikilinked, which isn't picked up as a case to avoid spacing like if it were unlinked. This is also a problem with other markup: at Japanese verb conjugation it is applied to "kaban o motte iru" only when "iru" is bolded and the markup is between the letters and the parenthesis. I am not sure if the initial minor kerning problem is worth fixing if the solution needs to be become increasingly Frankenstein-y. — Goszei (talk) 01:52, 10 June 2021 (UTC)

I think that the gap should be at maximum .15em, which is what is applied by templates in the Template:'" family. — Goszei (talk) 01:57, 10 June 2021 (UTC)

Thanks for the feedback, and thanks even more so for identifying it as a bug caused by assuming wiki markup is a text-character.

As for your opinion about the maximum being .15em, I'll test it out in the sandbox.

An unforseen consequence of catering to punctuation characters. A compromise is to remove punctuation characters from automatic kerning overlap prevention, but ideally the code could be enhanced to differentiate wiki markup from punctuation text. I might be able to address the bug.

Wish me luck! — JKVeganAbroad (talk) 13:23, 10 June 2021 (UTC)

• example (example) ← {{Nihongo/sandbox|example||example}}

  example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">example</i></span>)</span>

• example (example) ← {{Nihongo/sandbox|example||[[example]]}}

  example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">[[example]]</i></span>)</span>

• example (example) ← {{Nihongo/sandbox|example||'''example'''}}

  example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">'''example'''</i></span>)</span>

• example (example) ← {{Nihongo/sandbox|example||[[example|'''example''']]}}

  example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">[[example|'''example''']]</i></span>)</span>

• example (example) ← {{Nihongo/sandbox|example||'''[[example]]'''}}

  example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">'''[[example]]'''</i></span>)</span>

—Trappist the monk (talk) 13:36, 10 June 2021 (UTC)

@Trappist the monk fixed the code already, what a champion! I updated the sandbox to use the .15em that you suggested, and it looks fine to me; I have no objections. I support the proposed updated code. — JKVeganAbroad (talk) 14:59, 10 June 2021 (UTC)

Nice fix. On my browser (Chrome), I find that .05em is sufficient to totally eliminate the bad kerning. Results may vary, but .05 looks the most natural to me, while .1em and .15em definitely raise an eyebrow as "noticeable", and stand out too much when reading. I would agitate for a value of .05, or the lowest that we can go above that. — Goszei (talk) 16:51, 10 June 2021 (UTC)

Honestly .1em wasn't enough for my system, so I'm a little concerned you want it thinner. Is there a way to see what you're seeing? i.e. screenshots? For reference, I'm running macOS, tested on Firefox, Chrome, Edge, Safari (the OS and the software are all the current versions). Furthermore, Safari in particular seemed to have an uncomfortably thinner gap than the other browsers (i.e. too thin at 0.15em). — JKVeganAbroad (talk) 17:25, 10 June 2021 (UTC)

Here is a screenshot: [1] (running Chrome on Windows 10). I suppose it is a matter of personal taste somewhat as well, but I think 0em looks weird, .05em looks the most natural, that 0.1 is pushing it, and that .15 is too much, and approaches my brain reading that as "an errant space". "Totally eliminate" was an exaggeration, judging by the "f" in particular, but overall I think it is most acceptable. I did this screenshot in my sandbox (Special:Permalink/1027919750), and inspected the page and manually changed the values. Here is a version that can be used to compare: Special:Permalink/1027922382. — Goszei (talk) 19:32, 10 June 2021 (UTC)

I also solicited from screenshots from users in the WP:DISCORD, and this is what they look like : [2] [3] [4] [5]. — Goszei (talk) 20:06, 10 June 2021 (UTC)

Thanks for those crowdsourced screenshots, I understand what the problem is now. The fonts are different, comparing the Microsoft environment to the Apple environment (and presumably Linux). The gaps are significantly larger in those screenshots compared to my devices.

Hmm, what should we do? Is there way for CSS to target iOS and macOS environments to have a larger margin-gap? — JKVeganAbroad (talk) 15:01, 11 June 2021 (UTC)

Comment: Sorry to sound negative, but this whole enterprise (I mean "kerning issue", not "Wikipedia") seems to be ill-conceived. If on some system, with some font, some spacing is non-ideal, this is a problem for the font. It is completely inappropriate to go around trying to improve this in just one tiny corner of Wikipedia. Can someone show some test cases, with image captures, so we can see whether this is genuinely a general issue for all systems. (I understand that in a very specific situation, where you are producing fixed (i.e. print) output, it may be appropriate to make specific adjustments. Personally I have been known to jiggle the spacing with css when making a poster with the word ピアノ, because katakana was "really" meant to be vertical, where it looks fine, but when written horizontally the gap between ア and ノ opens up a kind of "river", and moving ア a smidgen to the right gives better balance. But I would not dream of suggesting going through WP making this sort of global edit...) Imaginatorium (talk) 18:14, 11 June 2021 (UTC)

I agree with Imaginatorium. I question the wisdom of a CSS solution for the issue of kerning, as it evidently has highly unpredictable results across different systems and fonts. Perhaps a solution could be implemented elsewhere (some Googling indicates there is a CSS property for this? perhaps could be implemented higher-up, or just applied locally by a user), but I don't think doing so in a template is an appropriate way of handling this. — Goszei (talk) 20:18, 11 June 2021 (UTC)

I disagree with the notion of "If it's a problem with the client's system then we won't attempt to fix it". If a reasonable workaround can be ascertained, then there's really no reason to intentionally not discover it. Also, we're talking about Apple systems here, that's no insignificant type of system (and the most universally consistent one at that). Thirdly, I'd argue that the inconvenience of a perceived erroneous space is a lesser problem than unreadable overlapping characters (accessibility is more important). Fourthly, CSS is highly standardised and not particularly unpredictable across different systems these days; rather than inconsistent CSS margin widths, the true issue is uncontrollable fonts with irregular widths.

As for test cases with screenshots, there are the sandbox test cases at the bottom of the pages (nihongo testcases, nihongo krt testcases). Feel free to add more test cases. If you have access to any Apple device you'll see the problem, but as for screenshots, where do you want them?

Also, I'll ask again, is there a way to use CSS to target Apple systems?

— JKVeganAbroad (talk) 12:09, 12 June 2021 (UTC)

Hmm. It is not just a question of not wanting to kludge round some problem, it's also a question of how/where to do it. Basically if all Apple fonts(??) have a bug that makes some italic letters crash into a non-italic closing parenthesis, then to work around this needs some very high level kludge in the WP style sheets, so this is mended everywhere, not just in the nihongo template. (An odd place for it to be a problem, because I would expect italics within non-italic parentheses to be Hepburn, and no normal Japanese word in Hepburn ends with a letter with an ascender, does it?)

You can sense (kludgily) whether you have an Apple device in css, as in this Stackoverflow question. But this would have to be in the stylesheet, not embedded in inline css, which I think is all that a template can generate.

My knowledge of typography is very much at the dilettante level; aren't parentheses around italics meant to be italic too? Input from a typography expert might help. About the testcases: what we need is a sample of the problem shown with the prekludge template, with image captures from different systems. If someone starts this, I will be happy to upload a picture of what I see (Linux something). Imaginatorium (talk) 14:19, 12 June 2021 (UTC)

You're right, there's no appropriate means to address a specific system. "kludge" is not the way.

After doing some reading and light testing, there might be a better CSS workaround that minimizes the impact. We can change the CSS style of the first or final letter (in the specific cases where kerning is desired):

(<span style="letter-spacing:.08em;">''pi''</span>) renders: (pi)

If the (pi) above looks good across all browsers/systems, then this workaround is better than the margin-gap workaround. — JKVeganAbroad (talk) 15:45, 12 June 2021 (UTC)

Um, not so good methinks. For the sake of exaggeration:

(<span style="letter-spacing:5em;">''pi''</span>) → (pi)

If this is indeed a global (to Wikipedia) problem, then it seems to me that the global solution is to:

1. confirm that readers and editors think that it is a problem
2. determine whether brackets that wrap italic text should be upright or should also be italicized; best done at one of the MOS: talk pages?
3. if brackets are not to be italicized, determine if it is possible to reliably detect user agent details an apply some sort of appropriate css; may require MediaWiki developer action

That list may be incomplete.

—Trappist the monk (talk) 16:02, 12 June 2021 (UTC)

Since the nihongo module uses a hybrid of non-italicised text and italicised text, I think it seems odd to make the pair of parenthesis in italics... (and let's not even consider only one of the parenthesis in italics, omg). But I guess it's stranger still that this hasn't been corrected in the entire history of Wikipedia.

As for the exaggeration, unless you're trying to convey that you see a big gap at .08em, I'm not sure I follow what you're trying to say? I mean, to use an analogy, a little bit of medicine is the cure, too much medicine is poison. So we should consider using as little medicine as we need, right?

Do we really need, for just a limited set of characters under 7 specific scenarios, to request a global solution for all of Wikipedia? To be clear, I don't oppose this idea, it's the best possible outcome after all. — JKVeganAbroad (talk) 17:08, 12 June 2021 (UTC)

I was trying to show that in your example, letter-spacing applies to all characters in the <span>...</span>

(some pi) ← (<span style="letter-spacing:5em;">''some pi''</span>)

But, written another way, cf:

(some pi) ← (''some p<span style="letter-spacing:5em;">i</span>'')

(some pi) ← (''some pi''<span style="margin-left:5em;">)</span>

These look the same to me.

If the problem (italicized characters clashing with upright parentheses) is not restricted to limited set of characters under 7 specific scenarios but occurs more broadly such that the community (once made aware of the problem) believe that readability is impaired, then the wider community should decide if the problem is sufficiently significant to warrant a significantly sufficient solution (yeah, I like alliteration). A significantly sufficient solution would likely require changes to MediaWiki:Common.css and, to reliably detect user's agent, perhaps changes to the Mediawiki javascript suite.

—Trappist the monk (talk) 18:12, 12 June 2021 (UTC)

Ahh, I wasn't clear enough about my example. My example was a stripped-down bare-bones "proof of concept", using only 2 problematic kerning characters as the first and final character, and not the intended for the final code. If my (pi) example looks bad at .8em, then the proposed "solution" will also fail for all other cases; however if the (pi) example looks okay, then we can proceed with more tests (comparing screen-captures) to see if it's viable. The span shouldn't capture the entire romaji word for this workaround, or the result will be the problem you exhibited.
I guess you're right though, that a Mediawiki change would benefit everyone. I have no idea how to go about this.
Edit: You're right, letter-spacing vs margin-left renders a pixel-perfect replica of each other, this is not the solution either. Damn. — JKVeganAbroad (talk) 03:06, 13 June 2021 (UTC)
Me again. @Trappist the monk, for the time being, would you be able to consolidate the wiki-markup bug-patch to the Nihongo main code? — JKVeganAbroad (talk) 11:25, 13 June 2021 (UTC)

I don't know what it is that you are asking. What wiki-markup bug-patch? Consolidate how or with what?

—Trappist the monk (talk) 11:35, 13 June 2021 (UTC)

To be more specific, this patch that you made to the sandbox fixes the bug where wiki-markup is parsed as valid characters requiring kerning. If you could consolidate this code variance with the nihongo module, it would stop the errors that Goszei noticed at the start of this discussion. — JKVeganAbroad (talk) 12:56, 13 June 2021 (UTC)

done

—Trappist the monk (talk) 13:33, 13 June 2021 (UTC)

Template-protected edit request on 18 June 2021 — Compromise: Reducing fringe cases

1029697775 I propose this compromise. As mentioned in the discussions above, perhaps we could italicise the parenthesis to solve the problem. I disagree with mix-matching unitalicised opening brackets with italicised closing brackets (or vise versa). However, in my proposal, I remove the fringe case where ENGLISH (ROMAJI) happens, by italicising the parenthesis in this case. This reduces the fringe cases to case 70 and 73 of nihongo test cases and 44, 47 and 48 of nihongo krt. That's 5 cases in total.

In addition, I did gradual testing and I'm okay to reduce the gap in these 5 fringe cases to 0.09em, as per the proposal.

What do you think?

JKVeganAbroad (talk) 02:17, 18 June 2021 (UTC)

Earlier in this train of discussions I wrote:

If this is indeed a global (to Wikipedia) problem, then it seems to me that the global solution is to:

1. confirm that readers and editors think that it is a problem
2. determine whether brackets that wrap italic text should be upright or should also be italicized; best done at one of the MOS: talk pages?
3. if brackets are not to be italicized, determine if it is possible to reliably detect user agent details an apply some sort of appropriate css; may require MediaWiki developer action

That list may be incomplete.

Have these issues been addressed? Where?

Out of curiosity, these searches:

insource:/[^']''\([^\)]+\)''/ 87,801

insource:/\(''[^'][^\)]+[^']''\)/ 312,111 (times out)

If there is any validity to these searches, then these results would suggest that editors prefer that upright parentheses bracket italicized text. If that is the case, then this edit request should not be honored.

—Trappist the monk (talk) 13:06, 18 June 2021 (UTC)

As per your regex search results, particularly given that the second one times out, I agree that this edit request should not be honored. I don't believe it's necessary to determine this at one of the Manual of Style pages, since the timed-out search results are rather conclusive—democratically—that italicizing the brackets is not preferred. So my opinion of your #2 point is that this has been determined, and brackets that wrap italic text should be upright.

As for point #1, this requires a poll of some sort, in a place of some sort.

As for #3, that can only really proceed after receiving the community opinion from point #1. If the community doesn't see a problem, then it's futile to investigate a solution.

So I guess I vote that point #1 should be a priority. However, in the meantime, the suggestion of removing the current kerning compensation implementation is not an idea I support. Readability > noticing erroneous spaces, in my opinion. — JKVeganAbroad (talk) 13:54, 19 June 2021 (UTC)

Template-protected edit request on 21 June 2021 — Compromise: Reducing width of compensation gap

I propose another compromise. I realise this is an ongoing discussion and that constantly updating the module whilst the code is contentious isn't an ideal situation, but perhaps changing the appearance of the kerning compensation gap will also change the perception of the discussion.

Regrettably, I suggested a change from .1em to .2em without proper testing. The larger gap appeared more comfortable at the time, but I now believe my perception was misjudged. I've since done a major lang/transl/nihongo template implementation on the Japanese grammar page to bring it in line with accessible HTML language markup, and that page uses the nihongo template extensively. It's clear to me that a .2em gap is excessive under a variety of italics lettering. Tweaking the CSS in my browser's developer kit proved that .09em is acceptable on my system.

The nihongo test cases and nihongo krt test cases indicate that the proposed code doesn't cause detectable failures, so it's possible to merge.

If possible, I'd like to see this code merged tentatively whilst we continue the discussion about the wider implications of kerning issues amongst different systems on Wikipedia.

— JKVeganAbroad (talk) 14:19, 21 June 2021 (UTC)

Comment: Briefly, I repeat my earlier comment. I think this project is ill-conceived. If the kerning rules for some fonts on some systems are less than satisfactory, the project has to be to get the kerning rules improved. Fiddling with a tiny corner of WP to kludge round this is not a good strategy, and will inevitably end up wasting someone else's time eventually, so I oppose the whole idea, even if revised, compromised, or whatever. Imaginatorium (talk) 15:30, 21 June 2021 (UTC)

…and will inevitably end up wasting someone else's time eventually… — I don't understand this argument. Before I took initiative to resolve this issue through the nihongo module, I used &​thinsp; on every occurrence in the nihongo romaji syntax. This was very inefficient: laborious, and added an annoying invisible character if people copied and pasted the text. But it resolved the kerning problem. After the code change was implemented on nihongo, it was also laborious to remove the &​thinsp; from the articles; however at least the problem was resolved for every nihongo code thereafter.

If this problem gets a global solution in the future, we only need to modify the code of one page: the nihongo module. That doesn't fit the definition of wasting time, in my opinion.

However the risk of not having a local solution is that other users might use &​thinsp; characters, or equivalent manual workarounds on a case-by-case basis, in the same way I did. We can't expect them to have the realisation to change the nihongo module themselves. Furthermore, it's clearly much more of a waste-of-time if a global solution is implemented and we have to seek out the manual &​thinsp; overrides people have used in the nihongo module to avoid kerning issues.

So in summary, I don't understand how this whole idea will inevitably end up wasting someone else's time eventually. Editing only the nihongo module itself is saving time, I think.

I can understand the other points you raised, though. — JKVeganAbroad (talk) 16:16, 21 June 2021 (UTC)

@JKVeganAbroad: Belated response to your reasonable question. Of course I can't say exactly how time will be wasted, but suppose your idea is followed through... Then there will be hundreds of templates like 'Nihongo' with kludgy edits to adjust the kerning on various combinations of letters in italic. (I was wrong, btw, in claiming that romanised Japanese doesn't end with letters with ascenders, because lowercase 'i' has the dot, which is in the position of an ascender.) Anyway, I think that your original technique of putting thin-space characters in various bits of WP text is the Wrong Way to approach the problem, and putting CSS adjustments in templates is also the Wrong Way. Undeniably, this Wrong Way is likely to waste less time than the original Wrong Way, but that doesn't make it the right way. Imaginatorium (talk) 11:34, 10 July 2021 (UTC)

 Not done The discussion below (at #Consensus?) renders this request moot. Procedurally declining. * Pppery * _{it has begun...} 19:20, 16 July 2021 (UTC)

Consensus?

Where does consensus stand right now on the live change? I believe that it should be reversed for now, pending a wider discussion of the problem and whether a solution that is somewhat consistent can be found. Pinging previous commenters in discussion. — Goszei (talk) 01:48, 18 June 2021 (UTC)

I am not sure what do with this discussion, as it seems to have stalled with a weak consensus against the implemented change (weak because there has only been 4 editors involved). I made several attempts to expand the discussion at WT:JAPAN and VPT to no avail. I am not sure the procedural path is here (maybe a reversal on Trappist's part, and then the opening of a wider thread in a more central venue? an RfC? I'm really not sure). I think all parties are interested in seeing more participation and a wider discussion of the problem.

I have pinged the two other involved editors here to discuss the procedural path forward. — Goszei (talk) 23:21, 4 July 2021 (UTC)

I support the suggestion for an RfC, because basically we need more opinions. — JKVeganAbroad (talk) 01:09, 5 July 2021 (UTC)

I have reversed the changes in question, due to the weak consensus against them at the present time. No prejudice to a future, neutrally-worded, and thorough RfC. — Goszei (talk) 05:20, 10 July 2021 (UTC)

I too am against solving font rendering kerning issues here in this Scribunto module. Frankly this is a hack to resolving the issue that should be solved in the browser or the fonts themselves. If we are proposing a hackish workaround for these issues, these should be handled in a single centralized place (e.g., a kerning module) which can be updated as the technology changes to fix the problem where it exists (i.e., the hack can be adjusted as the source of the problem gets resolved over time). I further think this should use CSS and not yield any Unicode characters such as thin or hair spaces that could get picked up when copying text (since kerning is not really a part of the text itself but how it is rendered). —Uzume (talk) 06:11, 12 July 2021 (UTC)

I'm disappointed with this outcome. Especially when Goszei proposed an RfC and then just decided "whatever, I'll just change it myself without doing the RfC". I'm also unsatisfied with the way it was reverted, because some of the newer revisions removed terminology from the code ("an experiment to implement...") but Goszei re-introduced it. Ultimately, I'm unwilling to pursue a global correction, since I don't have the skills or knowledge required, but I hope somebody does. This kerning issue is, after all, affecting every iPhone, iPad and macOS device on the planet, and that's no small minority worthy of dis-consideration. — JKVeganAbroad (talk) 03:22, 18 July 2021 (UTC)

Usage of 'lead=yes' parameter

There doesn't seem to be any official guidance for where and when to use the lead=yes parameter, and usage is irregular and sparse. Compare Mitsubishi (uses lead=yes) and Sony (doesn't use lead=yes) for example. There is also the suggestion above in this talk page that the parameter should not be used on biographical articles, i.e. where a Japanese name is the lead.

1. Is this parameter necessary in the first place? The suggestion is that the lead needs to identify to unfamiliar readers what language they are reading. Is this really necessary when most articles about Japanese companies, people etc. say that the subject is Japanese in the lead?
2. If the parameter is deemed necessary, should leads which are not using it be changed to use the parameter where appropriate, for example in Sony or Yamaha?
3. If the parameter is deemed necessary, should it be used on biographical articles? What about all other articles where the English name is a direct Hepburn romanization of the Japanese? (Example: Yorushika.)

— Jthistle38 (talk) 16:08, 7 January 2022 (UTC)

Does no one have an opinion on this matter? Or is this talk page completely unmonitored? — JThistle38 (talk) 19:10, 6 February 2022 (UTC)

This page is monitored; there are 85 editors who watch this page (whether all 85 are still active editors is an unknown). I suspect that the nature of this question has more to do with style than with the template itself. Perhaps your question is better asked at MOS:JAPAN (278 watchers) with notice to WT:JAPAN (464 watchers) – same caveats apply.

|lead=yes was added to {{nihongo}} as a result of this discussion from March–October 2011.

—Trappist the monk (talk) 19:35, 6 February 2022 (UTC)

Ok, I may bring it up there then. Many thanks. — JThistle38 (talk) 21:53, 6 February 2022 (UTC)

Literal translation inside parentheses?

This would be a useful option, the extra2 setting outside of the brackets only seems appropriate for the (niche?) case where it's being used in a deflist.

If this template is used at the start of an article's lead, having the literal translation outside of the brackets doesn't read well, the only options being to put the literal translation in its own, second set of brackets (as in the Sokoban article), or to not use the template. --Lord Belbury (talk) 09:22, 6 June 2022 (UTC)

What is wrong with using just the normal 'extra' parameter? i.e.

{{nihongo|'''''Sokoban'''''|倉庫番|''Sōko-ban''|{{lit|warehouse keeper}}}}

giving

Sokoban (倉庫番, Sōko-ban, lit. 'warehouse keeper')

— Jthistle38 (talk) 09:39, 6 June 2022 (UTC)

Oh! You're right, that's exactly what I needed, I must have missed it because the documentation examples don't include it. I'll add it there. Thank you. --Lord Belbury (talk) 09:47, 6 June 2022 (UTC)

Hepburn Romanizations don't follow normal rules?

The examples of Hepburn Romanizations seem to me to not follow the conventions used throughout the majority of English Wikipedia.

"Tokyo Tower" appears to be a proper noun, as it is written in English with both words capitalized. Why is the Hepburn Tōkyō tawā, as if the term isn't a proper noun, and not Tōkyō Tawā?

Why is Sōko-ban written with a hyphen? It's written Sōkoban in the word's English Wiktionary article, which follows the ALA-LC romanization rules for spacing romanization of Japanese. Tempjrds (talk) 23:53, 18 September 2022 (UTC)

If there is a fault with Tōkyō tawā and Sōko-ban, it is not the fault of the template but, rather, a fault in the choices made by editors using the template.

I don't know anything about Hepburn or ALA-LC romanizations (and I don't want to know), but I gotta wonder why you are using ALA-LC rules as evidence of someone's failure to follow Hepburn rules. That just doesn't make sense to me.

—Trappist the monk (talk) 00:25, 19 September 2022 (UTC)

Trappist: These are the example words used in the template docs. @Tempjrds: if you feel the docs can be improved in this regard, please go ahead and do so! It's worth noting that this template makes no demands about how words are romanized - it simply provides a way to easily lay out Japanese text with a corresponding English translation and romanization. It doesn't care what romanization method is used. Caring about that is the job of WikiProject Japan, I think. — Jumbo T (talk) 17:54, 20 September 2022 (UTC)

forking

Module:Nihongo was forked to support a new template {{hanyu}}. Forking is generally considered a bad thing so I have modified and updated Module:Nihongo so that it can support {{hanyu}} and other templates for non-Japanese text. Module:Nihongo should probably be renamed to reflect its ability to be language neutral though I haven't been able to think of a good name – if you know a good name for the generalized module, let me know. Adding set of {{nihongo}}-like templates for another language simply requires the addition of a set of configuration tables (located at the top of the module code).

Famous last words, this update should not have broken any existing {{nihongo}}, {{nihongo3}}, {{nihongo krt}}, or {{nihongo foot}} templates. If it did, please let me know.

—Trappist the monk (talk) 13:15, 8 October 2022 (UTC)

Abbreviation

Hi. What's the recommended usage syntax for including an abbreviation, please? For example, JEITA would preferably appear as follows:

Japan Electronics and Information Technology Industries Association (JEITA; Japanese: 社団法人電子情報技術産業協会, Hepburn: Shadan-hōjin Denshi Jōhō Gijutsu Sangyō Kyōkai)

Instead, it produces:

Japan Electronics and Information Technology Industries Association (Japanese: 社団法人電子情報技術産業協会, Hepburn: Shadan-hōjin Denshi Jōhō Gijutsu Sangyō Kyōkai, JEITA)

Thanks. fgnievinski (talk) 02:46, 2 June 2023 (UTC)

Excluding English label

I want to use this template without inserting English label. Every time I made that label empty, the template will include the English version of the Japanese automatically. I just need Kanji/Kana along with the romanization. Any help for this problem? ZanzibarSailor (talk) 23:49, 14 September 2023 (UTC)

I don't know what you mean by English label. You can simply omit the English translation if that is what you're looking for:

{{Nihongo||東京タワー|Tōkyō tawā}} → Tōkyō tawā (東京タワー)

or you can use {{transliteration}} and {{lang}} to make a custom rendering:

{{transliteration|ja|Tōkyō tawā}} ({{lang|ja|東京タワー}}) → Tōkyō tawā (東京タワー)

—Trappist the monk (talk) 00:25, 15 September 2023 (UTC)