Template talk:Nihongo

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)

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)

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)

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)

Any support for square brackets?

Any support for square brackets to use within parentheses? —  AjaxSmack  14:09, 11 March 2024 (UTC)

What support do you think is required? Inputs to the template may include square brackets. Always give a real-life example of what you think does not work.

—Trappist the monk (talk) 14:26, 11 March 2024 (UTC)

Just the standard (if not universal) use of square brackets for nested parentheticals. It's come up in edits I've made in the past, but I don't remember where. I usually just avoid this template when I'm writing and recast the sentence when I'm editing. Here's a hypothetical case though: "The bowed legs of the table (despite the Japanese name sabi-wabi (寂び侘び)) are neither subdued nor austere." While in this case I would replace the parentheses (brackets) with commas, in other cases it won't work, like in "The 45 cm (1.5-shaku (尺)) flute is an integral part of the orchestra." —  AjaxSmack  00:03, 12 March 2024 (UTC)

First off, if you are going to use this template, use it correctly. Above you wrote:

• {{Nihongo|''sabi-wabi''|寂び侘び}} → sabi-wabi (寂び侘び)
• {{Nihongo|''shaku''|尺}} → shaku (尺)

You should have written:

• {{Nihongo||寂び侘び|sabi-wabi}} → sabi-wabi (寂び侘び)
• {{Nihongo||尺|shaku}} → shaku (尺)

Yeah, the renderings look the same but in fact they aren't; cf:

• ''sabi-wabi''<span style="font-weight: normal"> (<span title="Japanese-language text"><span lang="ja">寂び侘び</span></span>)</span>
• <span title="Hepburn transliteration"><i lang="ja-Latn">sabi-wabi</i></span><span style="font-weight: normal"> (<span title="Japanese-language text"><span lang="ja">寂び侘び</span></span>)</span>

Pretty sure that we could add a parameter, |use-square-brackets=yes (default case no) or some such, that would cause Module:Nihongo to render square brackets instead of parentheses.

—Trappist the monk (talk) 00:55, 12 March 2024 (UTC)

Thanks for the usage tip. Such arcanity is why I usually avoid this template. —  AjaxSmack  03:32, 12 March 2024 (UTC)

Support for kanji and kana?

Is there any way to get this template display kanji and kana in separate fields. Many plants in Japanese use both katakana and kanji depending on the context (e.g. "Called seri (セリ; 芹) in Japanese, it is..." from Oenanthe javanica.) Cf. {{zh}} where you can get things like 台灣國; 台湾国; Tâi-oân-kok; ㄉㄞˊㄨㄢˊㄍㆦㆻ. —  AjaxSmack  17:54, 22 August 2024 (UTC)

Comes the editor who, in another discussion on this page, wrote: Such arcanity is why I usually avoid this template. Asking for yet more arcanity?

I can imagine new parameters. If any one of them is present, the value assigned to the second positional parameter would be ignored – the second positional parameter would still be required so that the third positional parameter works. Apparently there are three Japanese writing systems. If we are to consider this, is it worth supporting all of them?

katakana – |kana=; ISO 15924 script Kana

kanji – |kanji=; ISO 15924 script Hani

hiragana – |hira=; ISO 15924 script Hira

If we do this what should the rendering look like when more than one of these script specific texts are used in a {{nihongo}} template?

—Trappist the monk (talk) 20:07, 22 August 2024 (UTC)

​Thanks for your time on this. "Comes the editor ... Asking for yet more "arcanity"?" Touché. The kind of arcanity I was referring to is how {{nihongo}} operates quite differently from other similar language templates. Adding optional features, while technically arcane, does not require all users to know these.

"[T]he value assigned to the second positional parameter would be ignored – the second positional parameter would still be required..." Like this: {{nihongo|seri|​|kana=セリ|kanji=芹}} → seri (katakana: セリ; kanji: 芹), or do you mean there'd actually need to be text in the second positional parameter?

"[I]s it worth supporting all of them?" Well, they're already supported; it's a matter of being able to provide them separately so that they could be labeled.

"If we do this what should the rendering look like..." I'm not sure what you mean. Do you mean should they be labeled or should they be in a certain order or...? I am an interloper from the world of {{zh}} where linked labels, unlinked labels, no labels and reordering parameters are all possible. —  AjaxSmack  00:08, 15 September 2024 (UTC)

{{lang}} was created 25 January 2005; {{nihongo}} was created 9 October 2005‎; {{lang-zh}} was created (as {{zh}}?) 18 September 2009‎; all by different editors so you should not be surprised that they all operate differently.

Yeah, like that mostly

{{nihongo|seri||kana=セリ|5=kanji=芹|lead=yes}}

might render something like this:

seri (katakana: セリ; kanji: 芹)

without |lead=

{{nihongo|seri||kana=セリ|5=kanji=芹}}

might render something like this:

seri (セリ; 芹)

Not what I meant. What I'm asking is: should we support all three writing systems with three separate parameters: |kata=<katakana text>, |kanji=<kanji text>, |hira=<hiragana text>?

Labeling is linked to |lead= so it is important that whatever ordering we choose, it should be consistent, labeling or no.

—Trappist the monk (talk) 14:43, 15 September 2024 (UTC)

So I've hacked Module:Nihongo/sandbox to use |kana= and |kanji=:

• {{nihongo/sandbox|seri|some stuff that gets ignored|kana=セリ|kanji=芹|lead=yes}} – ignores whatever is in {{{2}}}

  seri (Japanese: some stuff that gets ignored)

• {{nihongo/sandbox|seri||kana=セリ|kanji=芹|lead=yes}} – ignores empty {{{2}}}

• {{nihongo/sandbox|seri||kana=セリ|kanji=芹}} – kana and kanji no lead

• {{nihongo/sandbox|seri||kana=セリ|lead=yes}} – kana

• {{nihongo/sandbox|seri||kana=セリ}} – kana no lead

• {{nihongo/sandbox|seri||kanji=芹|lead=yes}} – kanji

• {{nihongo/sandbox|seri||kanji=芹}} – kanji no lead

I need to rewrite what I've done so that I can incorporate |hira=

—Trappist the monk (talk) 22:31, 15 September 2024 (UTC)

Why are the romanizations huge?

Looking at an article like Hikikomori, the term "Hikikomori" is in a significantly larger font size than surrounding text, which looks really unprofessional. Is there a good reason for this? (I'm on Safari on a Mac, in case that matters.) Toadspike [Talk] 21:04, 6 November 2024 (UTC)

For {{nihongo}}, the ordering of parameters is:

{{Nihongo|<english>|<kanji/kana>|<rōmaji>|<extra>

That mess at the start of Hikikomori is:

{{nihongo||ひきこもり {{lang|en|or}} 引きこもり| '''Hikikomori'''| {{small|[[Literal translation|lit.]] }}"pulling inward, being confined"|lead=yes}}

Hikikomori (Japanese: ひきこもり or 引きこもり, lit. "pulling inward, being confined")

<span title="Hepburn transliteration"><i lang="ja-Latn">'''Hikikomori'''</i></span><span style="font-weight: normal"> ([[Japanese language|Japanese]]: <span lang="ja">ひきこもり <span title="English-language text"><span lang="en">or</span></span> 引きこもり</span>, <span style="font-size:85%;">[[Literal translation|lit.]]&nbsp;</span>"pulling inward, being confined")</span>

In the final rendering, 'Hikikomori' is marked up as ja-Latn. There have been times when editors have complained that {{nihongo}} or it underlying Module:Lang is doing something funny with fonts. Neither of these apply fonts; that is the responsibility of your browser

Does what you are seeing look like this:

<i lang="ja">'''Hikikomori'''</i>

Hikikomori

With my browser (chrome win 10), 'Hikikomori' isin the above example is rendered with a finer slightly smaller font. Some browsers don't properly distinguish between the lang="ja" and lang="ja-Latn" html attributes.

Also, the gloss in <extra> should be using single quotes.

—Trappist the monk (talk) 23:52, 6 November 2024 (UTC)

Thanks for the explanation. If I understand correctly, we're sticking with this because it's correct markup, and browsers just happen to display it in an ugly way? Toadspike [Talk] 09:35, 7 November 2024 (UTC)

Yes.

—Trappist the monk (talk) 14:21, 7 November 2024 (UTC)

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)