![]() |
Template:Nihongo is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
![]() | This template does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
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)
{{Nihongo|'''Kyoto Animation Co., Ltd.'''|株式会社京都アニメーション|Kabushiki-gaisha Kyōto Animēshon|lead=yes}}, often...
The '''French Navy''' ({{lang-fr|Marine nationale|lit=National Navy}}), informally "{{lang|fr|La Royale}}", is...
The '''Shang dynasty''' ({{zh|c={{linktext|商朝}}|p=Shāngcháo}}), also
{{
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'' (SSBN 640)''', the...
'''USS ''Will Rogers'' (SSBN-659)''' was...
{{nihongo}}
; if it were, then Benjamin Franklin wouldn't exhibit the problem...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)
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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.
{{
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?){{
nihongo}}
, {{
nihongo3}}
, and {{
nihongo foot}}
, with the parameters in the same positions.Since I'm talking about consistency, the template name should probably be
{{
nihongo krt}}
(instead of {{nihongo-krt}}
)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.
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)
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
 
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'')
– no space''l'')
– generic space''l'')
–  
'''''l''''')
– no space'''''l''''')
– generic space'''''l''''')
–  
''l''<span style="margin-left:.1em">)</span>
– css'''''l'''''<span style="margin-left:.1em">)</span>
– css![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
%s
(wtf?!) Why aren't they unique? Hahaha omg plz halp). So basically my own shortcomings are the reason I proposed this workaround. EDIT: .1em
to .2em
, and it looks marvelous. So much better for the opening and closing parenthesis brackets.@ 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)
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)
{{Nihongo/sandbox|example||example}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">example</i></span>)</span>
{{Nihongo/sandbox|example||[[example]]}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">[[example]]</i></span>)</span>
{{Nihongo/sandbox|example||'''example'''}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">'''example'''</i></span>)</span>
{{Nihongo/sandbox|example||[[example|'''example''']]}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">[[example|'''example''']]</i></span>)</span>
{{Nihongo/sandbox|example||'''[[example]]'''}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">'''[[example]]'''</i></span>)</span>
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)
(<span style="letter-spacing:.08em;">''pi''</span>)
renders: (pi)(<span style="letter-spacing:5em;">''pi''</span>)
→ (pi)letter-spacing
applies to all characters in the <span>...</span>
(<span style="letter-spacing:5em;">''some pi''</span>)
(''some p<span style="letter-spacing:5em;">i</span>'')
(''some pi''<span style="margin-left:5em;">)</span>
limited set of characters under 7 specific scenariosbut 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.
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)
wiki-markup bug-patch? Consolidate how or with what?
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
If this is indeed a global (to Wikipedia) problem, then it seems to me that the global solution is to:
- confirm that readers and editors think that it is a problem
- determine whether brackets that wrap italic text should be upright or should also be italicized; best done at one of the MOS: talk pages?
- 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.
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
nihongo module
, I used  
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  
from the articles; however at least the problem was resolved for every nihongo code thereafter.nihongo module
. That doesn't fit the definition of wasting time, in my opinion. 
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  
overrides people have used in the nihongo module to avoid kerning issues.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)
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)
[[Hepburn romanization|হেপবার্ন]]
to [[হেপবার্ন রোমান লিপি|হেপবার্ন]]
yourself.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.
— 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)
|lead=yes
was added to {{
nihongo}}
as a result of
this discussion from March–October 2011.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)
{{nihongo|'''''Sokoban'''''|倉庫番|''Sōko-ban''|{{lit|warehouse keeper}}}}
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)
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)
Hi. What's the recommended usage syntax for including an abbreviation, please? For example, JEITA would preferably appear as follows:
Instead, it produces:
Thanks. fgnievinski ( talk) 02:46, 2 June 2023 (UTC)
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)
English label. You can simply omit the English translation if that is what you're looking for:
{{Nihongo||東京タワー|Tōkyō tawā}}
→ Tōkyō tawā (東京タワー){{
transliteration}}
and {{
lang}}
to make a custom rendering:
{{transliteration|ja|Tōkyō tawā}} ({{lang|ja|東京タワー}})
→ Tōkyō tawā (東京タワー)Any support for square brackets to use within parentheses? — AjaxSmack 14:09, 11 March 2024 (UTC)
{{Nihongo|''sabi-wabi''|寂び侘び}}
→ sabi-wabi (寂び侘び){{Nihongo|''shaku''|尺}}
→ shaku (尺){{Nihongo||寂び侘び|sabi-wabi}}
→ sabi-wabi (寂び侘び){{Nihongo||尺|shaku}}
→ shaku (尺)''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>
|use-square-brackets=yes
(default case no
) or some such, that would cause
Module:Nihongo to render square brackets instead of parentheses.![]() |
Template:Nihongo is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
![]() | This template does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
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)
{{Nihongo|'''Kyoto Animation Co., Ltd.'''|株式会社京都アニメーション|Kabushiki-gaisha Kyōto Animēshon|lead=yes}}, often...
The '''French Navy''' ({{lang-fr|Marine nationale|lit=National Navy}}), informally "{{lang|fr|La Royale}}", is...
The '''Shang dynasty''' ({{zh|c={{linktext|商朝}}|p=Shāngcháo}}), also
{{
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'' (SSBN 640)''', the...
'''USS ''Will Rogers'' (SSBN-659)''' was...
{{nihongo}}
; if it were, then Benjamin Franklin wouldn't exhibit the problem...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)
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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.
{{
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?){{
nihongo}}
, {{
nihongo3}}
, and {{
nihongo foot}}
, with the parameters in the same positions.Since I'm talking about consistency, the template name should probably be
{{
nihongo krt}}
(instead of {{nihongo-krt}}
)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.
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)
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
 
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'')
– no space''l'')
– generic space''l'')
–  
'''''l''''')
– no space'''''l''''')
– generic space'''''l''''')
–  
''l''<span style="margin-left:.1em">)</span>
– css'''''l'''''<span style="margin-left:.1em">)</span>
– css![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
%s
(wtf?!) Why aren't they unique? Hahaha omg plz halp). So basically my own shortcomings are the reason I proposed this workaround. EDIT: .1em
to .2em
, and it looks marvelous. So much better for the opening and closing parenthesis brackets.@ 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)
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)
{{Nihongo/sandbox|example||example}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">example</i></span>)</span>
{{Nihongo/sandbox|example||[[example]]}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">[[example]]</i></span>)</span>
{{Nihongo/sandbox|example||'''example'''}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">'''example'''</i></span>)</span>
{{Nihongo/sandbox|example||[[example|'''example''']]}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">[[example|'''example''']]</i></span>)</span>
{{Nihongo/sandbox|example||'''[[example]]'''}}
example<span style="font-weight: normal"> (<span title="Hepburn transliteration"><i lang="ja-Latn">'''[[example]]'''</i></span>)</span>
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)
(<span style="letter-spacing:.08em;">''pi''</span>)
renders: (pi)(<span style="letter-spacing:5em;">''pi''</span>)
→ (pi)letter-spacing
applies to all characters in the <span>...</span>
(<span style="letter-spacing:5em;">''some pi''</span>)
(''some p<span style="letter-spacing:5em;">i</span>'')
(''some pi''<span style="margin-left:5em;">)</span>
limited set of characters under 7 specific scenariosbut 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.
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)
wiki-markup bug-patch? Consolidate how or with what?
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
If this is indeed a global (to Wikipedia) problem, then it seems to me that the global solution is to:
- confirm that readers and editors think that it is a problem
- determine whether brackets that wrap italic text should be upright or should also be italicized; best done at one of the MOS: talk pages?
- 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.
![]() | This
edit request to
Module:Nihongo has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
nihongo module
, I used  
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  
from the articles; however at least the problem was resolved for every nihongo code thereafter.nihongo module
. That doesn't fit the definition of wasting time, in my opinion. 
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  
overrides people have used in the nihongo module to avoid kerning issues.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)
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)
[[Hepburn romanization|হেপবার্ন]]
to [[হেপবার্ন রোমান লিপি|হেপবার্ন]]
yourself.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.
— 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)
|lead=yes
was added to {{
nihongo}}
as a result of
this discussion from March–October 2011.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)
{{nihongo|'''''Sokoban'''''|倉庫番|''Sōko-ban''|{{lit|warehouse keeper}}}}
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)
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)
Hi. What's the recommended usage syntax for including an abbreviation, please? For example, JEITA would preferably appear as follows:
Instead, it produces:
Thanks. fgnievinski ( talk) 02:46, 2 June 2023 (UTC)
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)
English label. You can simply omit the English translation if that is what you're looking for:
{{Nihongo||東京タワー|Tōkyō tawā}}
→ Tōkyō tawā (東京タワー){{
transliteration}}
and {{
lang}}
to make a custom rendering:
{{transliteration|ja|Tōkyō tawā}} ({{lang|ja|東京タワー}})
→ Tōkyō tawā (東京タワー)Any support for square brackets to use within parentheses? — AjaxSmack 14:09, 11 March 2024 (UTC)
{{Nihongo|''sabi-wabi''|寂び侘び}}
→ sabi-wabi (寂び侘び){{Nihongo|''shaku''|尺}}
→ shaku (尺){{Nihongo||寂び侘び|sabi-wabi}}
→ sabi-wabi (寂び侘び){{Nihongo||尺|shaku}}
→ shaku (尺)''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>
|use-square-brackets=yes
(default case no
) or some such, that would cause
Module:Nihongo to render square brackets instead of parentheses.