Template talk:ja-kanjitab

Shinjitai vs Kyujitai etc

Why is it that this template does not handle both kyūjitai and shinjitai forms in the same way that the equivalent Chinese template handles both simplified and traditional forms?

The "etc" in the subject/headline refers to the process by which characters not in the Toyo kanji are more or less systematically replaced by similar looking or sounding Toyo characters. My favourite example being old 濠洲 vs new 豪州. — hippietrail 15:37, 18 December 2008 (UTC)

There is one profound difference: in (e.g.) Mandarin, both the simplified and traditional forms are in current use; current being say the last 1/2 century. In Japanese, the kyūjitai are of historical interest (as you note, sometimes quite interesting), but are not used in ordinary Japanese since ~1947. Certainly we'd eventually like to have entries for words that can be attested before then, and the hold-overs, but that is not the majority of the entries describing the current language. (Unlike Mandarin etc.) Robert Ullmann 16:33, 18 December 2008 (UTC)

But this is not true. I find them in use all the time. 龍 is particularly common and is the second choice offered by my IME for りゅう. Also it is very recent history. Only after world war II was shinjitai put in place. War era Japanese is of great interest in the west and without good coverage of kyujitai we are doing a disservice to people in need of a dictionary to help investigate writing of this era. Any we do already have some support for kyujitai, I have included kyujitai spellings myself in the past few years. I'm merely wondering why ja-kanjitab is not one of the places that takes kyujitai into account. — hippietrail 00:03, 19 December 2008 (UTC)

I knew you would whine: I tried to make it clear: YES WE WANT TO COVER KYUJITAI. This is ONLY ABOUT WHY IT ISN'T IN KANJITAB for all entries to show both. Clear yet? In Mandarin one wants to be able to switch back and forth easily because they are both current (and not-"current" in no way means "ancient", it just means an effing half an effing century!) For example, the zh.wp has variant tabs to switch back and forth. The ja.wp does not, because it would be nonsense. (w:jp:濠洲 is redirected.)

{{zh-forms}} is set up to be helpful in showing both forms presently useful in Mandarin (et al) entries. kanjitab is set up to show the one form. (And not id'd as such, it is useful for kyūjitai entries too.) (and cf. {{ko-hanjatab}}, where of course there is only one form shown.)

I added the form reference into the entry. 濠洲 See? (:-) Robert Ullmann 11:59, 19 December 2008 (UTC)

Heh I don't want to force anyone else to work on it. I'm working on it myself and want to do it right. Sorry but I had to revert your change to 濠洲 because that's not a case of kyujitai vs shinjjitai but another spelling reform phenomenon which I mentioned in my second paragraph. — hippietrail 13:16, 19 December 2008 (UTC)

Don't waste time trying to "improve" this template: if you want to show the forms use {{ja-forms}}. And if your example wasn't what you were complaining about, then what were you complaining about? Or what is a proper example? There isn't anything to "fix" here. Robert Ullmann 12:00, 20 December 2008 (UTC)

Thank you for being opinionated and stubborn and telling people what to do. Don't waste your time "helping" next time. JUST POINT TO THE OTHER TEMPLATE. Now I have to wonder when on earth simplified Chinese became a "ja-form" but that's a question for another talk page. — hippietrail 15:30, 20 December 2008 (UTC)

I'm sorry, I didn't realize that you were completely unaware of the other, which is part of the reason I couldn't figure out what you were complaining about. It is odd that {{ja-forms}} which shows all the forms is documented in WT:AC and not in WT:AJ, but then most of the uses are for the individual characters. Sorry. Robert Ullmann 16:05, 20 December 2008 (UTC)

Thanks. I coudn't figure out why you seemed to be being mean when I was trying to be friendly. — hippietrail 01:36, 21 December 2008 (UTC)

Redirect

Since this is a Japanese template, wouldn't it make sense to automatically redirect to the Japanese section of each entry, similar to the way Template:term works? --Hikui87 20:26, 10 October 2009 (UTC)

Links to Translingual

Most of our kanji are definitionless pages, instead having a def in the Translingual section. However, kanjitab specifies #Japanese, so generally a mouseover with popups over this template is completely unhelpful. What do you think about changing the link so that it doesn't specify any section? --Μετάknowledge^{discuss/deeds} 12:42, 6 September 2012 (UTC)

Automatic detection

It is possible to automatically detect the characters with Lua probably without subtle difference in speed. It would be particularly useful when the user is auto-creating entries with a client-side code, e.g. a JavaScript tool, which affects the speed. --Z 06:23, 12 April 2013 (UTC)

See also

Template:kanji readings tab should also be under the “See also” section. 〜britannic124 (talk) 20:20, 16 August 2013 (UTC)

changes to kanjitab etc

@Eirikr, Wyang, Atitarev, Jamesjiao, TAKASUGI Shinji in no particular order, apologies if I left anyone out: some features I wrote into this template's module (Module:ja-kanjitab) may not have been brilliant ideas in the end, so feel free to remove or revise any of them. I won't be offended. I put a lot of thought into all of the changes I made but hindsight is clearer than foresight or nowsight or whatever. I did the grade 1,2../hyogaiji/jinmeiyo labels in imitation of other Japanese dictionaries that have little crosses or triangles next to the non-joyo kanji. Maybe it should be revised to look more like that. In the same vein, feel free to revise or remove any of the other code I've written. That's already the rule of wikis anyway, but I'm saying that on a personal level I won't be offended or upset. Haplogy (話) 01:55, 24 February 2014 (UTC)

Sokuon parameter and category?

Could we create a parameter and category for sokuoned words that are similar to those for rendaku words? Any questions? --Lo Ximiendo (talk) 05:01, 30 July 2014 (UTC)

I support the creation of a category but I think that inclusions should be determined automatically. Nibiko (talk) 05:38, 31 October 2016 (UTC)

Okurigana

There is unaddressed confusion regarding the okurigana parameter: https://en.wiktionary.org/wiki/Talk:%E5%B0%96%E9%BC%A0#kanjitab_readings Nibiko (talk) 03:32, 1 March 2015 (UTC)

I guess that one benefit of this could be generating the correct sort key, but this wouldn't apply to terms that have non-okurigana kana. Nibiko (talk) 04:54, 20 June 2017 (UTC)

Feature request: jukujikun readings

Something has been bothering me for a long time now, and it's the lack of ability to mark jukujikun, which are kun'yomi that are applied to multiple characters. See how the jukujikun are marked here in this entry in this dictionary: http://www.weblio.jp/content/%E5%A4%A7%E5%92%8C%E8%A8%80%E8%91%89 The current workaround that is generally being used is leaving the readings blank e.g. at 大和言葉. I think that we should at least mark them, instead of leaving them blank. As far as ideas go, one idea that I had was that a flag like "-" could be accepted as a mark that until a non-"-" argument is provided, all the kanji are a part of a jukujikun reading. Nibiko (talk) 16:22, 10 June 2015 (UTC)

I recall Eirikr wanting each reading to be marked as goon/kan'on/etc. Nibiko (talk) 15:09, 3 December 2016 (UTC)

Rendaku

I have seen r=y used in many words, but it's not described in the documentation. --Zalmoksis (talk) 14:35, 17 December 2015 (UTC)

It's explained just before the "Categorization" header. With the current state of the category including terms with ancestral rendaku and no instruction being given for discrimination hereupon, it might as well be determined just from the current data fed into ja-kanjitab, but restricting it to terms with rendaku in the immediate etymology would require a breakdown of the immediate etymology. Nibiko (talk) 04:12, 31 October 2016 (UTC)

Kanjitab and listing words by kanji characters

I edited the kanjitab for 奪う according to the guidelines and now the word disappeared form the Category:Japanese terms spelled with 奪. Is it an error or have I missed some crucial point? Zalmoksis (talk) 21:23, 1 November 2017 (UTC)

@Zalmoksis: -- The {{ja-kanjitab}} character adds kanji with Jōyō readings to characters like Category:Japanese terms spelled with 奪 read as うば. Once created with the proper templates (I've just done so), that category page in turn adds the contained entries to more generic categories, such as Category:Japanese terms spelled with 奪.

HTH, ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:29, 1 November 2017 (UTC)

Thanks for help. However, I still seem to be missing some important knowledge: I saw the category page: Category:Japanese terms spelled with 蒙, so I created the page Category:Japanese terms spelled with 蒙 read as もう using the appropriate template. But although all the entries seem to have correct ja-kanjitab templates they still appear on the main page instead of the newly created page with particular pronunciation. Zalmoksis (talk) 14:45, 2 November 2017 (UTC)

@Zalmoksis: -- Aha, I think I see what you're running into. A given kanji will only be added to a category like Category:Japanese terms spelled with 蒙 read as もう if that reading is a Jōyō ("standard-use") reading. If it is a Hyōgai ("off-the-chart") reading (i.e. not a reading included in the table of readings used in the standard Japanese curriculum), the {{ja-kanjitab}} template will not add the character to that category.

To check the categorization for a given kanji-spelled entry, have a look a the bottom of the page. On the 蒙 page, for instance, there is no listing for Category:Japanese terms spelled with 蒙 read as もう, since the mō reading is a Hyōgai reading. On the 奪 page, by contrast, there is a listing for Category:Japanese terms spelled with 奪 read as うば, since the uba- reading is part of the Jōyō standard. Kanji terms with Hyōgai readings are instead added to categories like Category:Japanese kanji with kan'yōon reading もう, as at the 蒙 page.

Ultimately, since the mō reading for 蒙 is Hyōgai, the Category:Japanese terms spelled with 蒙 read as もう page will never list anything, under our current implementation.

If you'd like to propose that Hyōgai readings are also considered for purposes of categorization, I'd suggest bringing up the topic at WT:BP, and pinging at least Wyang, as I think he's been the most involved in creating the data module framework used by these templates. ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:46, 2 November 2017 (UTC)

I'm not sure it works exactly as you say. The following kanji is entirely hyōgai: Category:Japanese terms spelled with 姦, so it has not a single jōyō reading, but it has the reading subcategory working correctly. Isn't it rather, say, the fact the reading もう of 蒙 is kan’yōon that prevents from inclusion? Zalmoksis (talk) 20:58, 2 November 2017 (UTC)

Walking through the code a bit, I found the relevant section. Have a look at Module:ja-kanjitab, and search the page for 姦 -- the basic flow is to only apply categories like Category:Japanese terms spelled with 蒙 read as もう for Jōyō, but for some reason, there's a list of exceptions to apply such categories to specific Hyōgai characters, and 姦 is one of them. It looks like @Erutuon and @suzukaze-c have worked on it most recently. Perhaps they can help elucidate what's going on? ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:46, 2 November 2017 (UTC)

The list of hyougaiji for which "read as" categories will be added was started in this edit by @Haplology. I don't know the rationale for it. — Eru·tuon 22:59, 2 November 2017 (UTC)

^ this. —suzukaze (t・c) 04:55, 3 November 2017 (UTC)

• I'm curious, what reasons are there for not categorizing by reading for hyōgaiji? ‑‑ Eiríkr Útlendi │^{Tala við mig} 05:13, 3 November 2017 (UTC)

Categorization mistakes caused by hyphens to show presence / lack of okurigana

I just noticed at 梅 (ume) that the template is incorrectly categorizing into Category:Japanese kanji with kun reading うめ-. Meanwhile, the expected Category:Japanese kanji with kun reading うめ (without the hyphen) doesn't exist, and doesn't have anything in it. Similarly, 光 (hikari) is incorrectly added to Category:Japanese kanji with kun reading ひかり-, which sits alongside the orthogonal older and correctly named Category:Japanese kanji with kun reading ひかり.

Could someone have a look at this and fix things? The general expectation is that the category name should not include hyphens if the reading is for a single kanji without okurigana, like 光 (hikari) or 桜 (sakura), etc. ‑‑ Eiríkr Útlendi │^{Tala við mig} 00:16, 18 November 2017 (UTC)

@Eirikr: That is the work of {{ja-readings}}, not {{ja-kanjitab}}. —suzukaze (t・c) 03:55, 18 November 2017 (UTC)

Derp. Thank you. Moving. ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:30, 20 November 2017 (UTC)

original reading of いっ

Is there any way to know if an 一(いっ) (i') was いち or いつ before sound change? --Dine2016 (talk) 03:32, 25 February 2018 (UTC)

Not that I'm aware of. @Shinji, are you aware of any such means? ‑‑ Eiríkr Útlendi │^{Tala við mig} 04:38, 25 February 2018 (UTC)

@Dine2016, Eirikr: I’d say it is always いち, because いつ is a reading used almost exclusively at the end of a word. The only exception is 一(いつ)に (itsuni) and I have confirmed that it is the only word on Daijisen that begins with 一 as いつ. The rest are いち or いっ.

There are several kanji whose kan'on is not used at the beginning of a word. 日 is always にち and 力 is always りき at the beginning of a word. (There may be exceptions though.) — TAKASUGI Shinji (talk) 05:06, 25 February 2018 (UTC)

kanji reading

I think kanji readings should be full morphemes, not just the part before the “okurigana point.” For example, 再び should be categorized as Category:Japanese terms spelled with 再 read as ふたたび, not just Category:Japanese terms spelled with 再 read as ふたた, in consistency with the official jōyō kanji list. --Dine2016 (talk) 10:41, 13 August 2018 (UTC)

I'm not sure I can agree. One consideration is that The Jōyō list targets JA speakers / readers, i.e. people who are assumed to already understand what okurigana are and how they work. Meanwhile, our target audience is English speakers / readers, who cannot be safely assumed to have any such knowledge.

Another consideration is that the proposed approach gets super complicated with inflecting terms. It sounds like this would imply that 見 would be under Category:Japanese terms spelled with 見 read as みる. What about conjugated forms? What about 見える? Similarly, this would imply that 良 would be under Category:Japanese terms spelled with 良 read as いい What about inflected forms like 良く? What about alternative "dictionary form" よい?

I think the motivation underlying the current system was to clarify what portion of the reading is "included" in the kanji, and what portion is explicitly spelled out in kana. In modern texts, 再び always has the び explicitly spelled out, and as such, the 再 kanji itself only covers the ふたた portion of the reading. If we state that 再 is read as ふたたび, that sensibly gives rise to the question of, what is the extra び for when the term is written out as 再び? Given that our readership has no presupplied familiarity with okurigana conventions, the proposed approach entails the risk that we wind up misinforming our users. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:57, 13 August 2018 (UTC)

@Eirikr: 再 is used to write the ふたた portion of ふたたび, but it is never "read" as ふたた, because that "form" cannot standalone without being followed by び. It is as nonsensical as saying that "1" is read as "fir" without giving context information. As a compromise, what about Category:Japanese terms spelled with 再 read as ふたた(び) or Category:Japanese terms spelled with 再 read as ふたた-び? This approach is not perfect because there are terms such as 合(あい), 合(あ)い (ai) whose okurigana usage is unstable—the ideal way is still to not mark the furigana-okurigana boundary at all—but this approach is much better than omitting okurigana completely.

As for inflection, note that 見える is lexicalized so it is a distinct word from 見る, just like 割れる vs 割る. So 見 is read as み(える) in 見える. 良く can be considered as having two readings よい and いい, the first fully inflectible and the second only found in 終止形 and 連体形, so any inflection is from よい and 良 read as よ(い), except when the term's reading explicitly have いい. The real difficulty comes from distinguishing verb 連用形 from derived noun or adjective 連用形 from derived adverb. For example, is the 話し in 話し方, 話し声, etc. a verb 連用形 or a noun? If the former, the 話 is read as はな(す); if the latter, it is read as はな(し). But it is never はな without context.

If we were to clarify what portion of the reading is "included" in the kanji, and what portion is explicitly spelled out in kana, then we should follow the approach of furigana.info and eliminate the |kn= and |on= parameters of {{ja-kanjitab}}, saying for example the reading of 放 is はな in 放し but ばな in 手放し. If we say that 放 is read as はな in 手放し, the reader will be as confused as if we said 再 is read ふたたび in 再び. --Dine2016 (talk) 06:10, 10 December 2019 (UTC)

On a second thought, I think including okurigana may be problematic. English "-ly" is productive, so "1" in "1stly" is still read as "first". But える (from classical ゆ) is not productive, so 見 in 見える is read as み(える). This is arbitrary and likely to confuse users without knowledge of morphology. What about Category:Japanese terms spelled with 再 covering ふたた? --Dine2016 (talk) 06:24, 10 December 2019 (UTC)

Thank you for considering these issues. This is a somewhat thorny problem space.  :)

I was first leaning towards [Kana intrinsic to the kanji spelling portion]-[Okurigana], to match what we put into {{ja-readings}}. However, as you note, okurigana are 1) somewhat unsettled for some words, and 2) not truly germane, as with 見(み) (mi)-[various endings]. For #1, it might make the most sense from a usability perspective to include both things like 合(あ)い (ai) and 合(あい) (ai), where both (or more?) permutations are common enough for readers to encounter.

Must crash, so that's all from me for now.  :) ‑‑ Eiríkr Útlendi │^{Tala við mig} 09:07, 10 December 2019 (UTC)

yutōyomi vs k,o

Discussion moved from Template talk:ja-pron

@Eirikr Hi. I noticed that you are using |yomi=k,o in edits like 滋籐. This causes the kanjitab to look differently from pages using |yomi=y (like 湯桶): the former generates two tabs “kun’yomi” and “on’yomi”, while the latter generates a single tab “yutōyomi” spanning two columns.

Is such an effect desirable? If not, I see two ways to solve it:

• Settle on a single editorial style: use either k,o or y, but not both.
• Make the module generate consistent output (either “kun’yomi + on’yomi” or “yutōyomi”) regardless of the input style.

(I once attempted to keep some morphological information in the yomi codes, such as giving 大和言葉 the reading juku2,k2, reflecting the structure of the term as yamato + kotoba rather than yamato + koto + (ha >) ba. But I now doubt it, and think 大和言葉 should get just juku2,k,k, because things become much simpler if kanjitab deals only with written forms and kanji, and because it can be sometimes misleading to deduce morphological information from the kanji spelling (e.g. ateji usages like 真(ま)っ当(とう) (mattō) and 切(キリ)支(シ)丹(タン) (kirishitan)).)

--Dine2016 (talk) 02:50, 13 September 2018 (UTC)

@Dine2016 -- You're right to bring up 滋籐, I think I got to that one during a spate of surname and given-name edits, and with the wild variance in name readings, my head was firmly in the new yomi=x,y,z mode. I just changed that to yutōyomi for the time being. However, now that you call my attention to it, I'm on the fence as to which is better -- using yutō and jūbako, or breaking things down to explicit on and kun. @TAKASUGI Shinji, Suzukaze-c, Wyang, any others, do you have opinions on this?

Incidentally, for bigger compounds like at the 湯桶読み entry itself, I noticed that yomi=y2,k errors out. But then perhaps it's better anyway to explicitly show kun and on.

Your idea of yomi=juku2,k2 for 大和言葉 sounds like a good one, FWIW. ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:24, 13 September 2018 (UTC)

Some other questions: should 消しゴム be categorized as a kun'yomi term? Should 気に入る be categorized as a jūbakoyomi term? I prefer to use “written forms” rather than “terms” in the category names. “Terms” should be categorized according to 語種, not 読み. --Dine2016 (talk) 01:17, 15 September 2018 (UTC)

Re: 消しゴム and other compounds with katakana, probably not.

Re: 気に入る and other phrases, these shouldn't have any entry-wide yomi category at all (though the component parts should have the proper yomi applied in {{ja-kanjitab}}, now that that is possible).

Re: terms vs. written forms, I have no strong opinions. Your point seems like a good one, so let's go with that. ‑‑ Eiríkr Útlendi │^{Tala við mig} 06:07, 15 September 2018 (UTC)

float: right / clear: right / floatright

There are a few edits over the last few months switching from an inline style float: right to the class floatright, and back: 1, 2, 3, 4.

The current state is "float: right", without the class "floatright". This produces wrong-looking results for me on pages where I've noticed it. For example:

There's a {{wikipedia}} box there, and the kanjitab box gets stuck to the left of the wikipedia box -- with no margin to separate the boxes, plus with a bit of vertical offset that makes it look misaligned.

A more natural layout would be to put the kanjitab box *below* the wikipedia box, aligned to the right of the page in the same way. The CSS way to specify that is to set clear: right. And indeed, if you set that on this box, in e.g. a browser's dev tools, the layout on that page becomes quite reasonable:

(Screenshots from Firefox. Chrome also produces the same results.)

And... setting the attribute clear: right in addition to float: right is exactly what the class floatright does. So from examples like this one, the thing I'd sure be inclined to do is to switch to the class floatright.

But that's exactly what @Dine2016 did, a couple of times; and they reverted that change themselves once, and later @Eirikr reverted it with the comment '"floatright" class behaves differently and is screwing up the layout of lots of pages; reverting to "float:right;"'. So I'd like to understand what *those* issues were (in particular, which pages were being screwed up?), so we can try to find a solution that works well for both kinds of pages. -Gnp (talk) 07:23, 29 April 2019 (UTC)

@Dine2016, Eirikr I just discovered the handy {{ping}} template (and the underlying feature). So, please see above! -Gnp (talk) 07:35, 29 April 2019 (UTC)

@Gnp: Thanks for bringing up this issue. Please see Module talk:ja-kanjitab. I think the boxes should normally be stacked vertically, too. --Dine2016 (talk) 10:54, 29 April 2019 (UTC)

Auto-categorizing as yutōyomi or jūbakoyomi, even without those specified -- not always desirable

Pinging @Dine2016:

I noticed over at 頑張れ that the page is added to Category:Japanese_terms_read_with_jūbakoyomi. I don't think this is correct. My understanding of 重箱読み, and 湯桶読み as well, is that these terms are used to describe the readings of two-character compounds that have no okurigana, in line with their eponymous terms, 重箱 (jūbako) and 湯桶 (yutō). Since 頑張れ, and main verb 頑張る, have okurigana, neither should be classed as jūbakoyomi or yutōyomi. I edited the {{ja-kanjitab}} parameters at 頑張れ to specifically avoid yomi=j here and here, and was dismayed to find that the Category:Japanese_terms_read_with_jūbakoyomi listing was still there at the bottom of the page.

I can see use cases for being able to specify on / kun per character, but also for being able to specify separately if a given compound is jūbako / yutō (assuming that the template can't be coded to automatically discern if there are any okurigana). Perhaps we need a reworking of the parameters? ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:46, 28 August 2019 (UTC)

I've modified Module:ja-kanjitab so that it only automatically adds the jūbakoyomi or yutōyomi category if the title consists of two characters (code points). — Eru·tuon 00:21, 29 August 2019 (UTC)

Spacing issue on entries with only one etymology

{{ja-kanjitab}} in Internet Explorer 11, Windows 10 64-bit; Dell Inspiron 5559, 1920×1080. Note the extra space left of {{ja-kanjitab|alt=}} parameter.

@Dine2016, Erutuon, see うずまき銀河 (uzumaki ginga, “spiral galaxy”).

When {{ja-kanjitab}} is put above the Etymology heading, sometimes the Pronunciation section (if there is one) might create a big space between that and the part of speech heading. Any thoughts? ～ POKéTalker（═◉═） 00:46, 30 August 2019 (UTC)

I'm not seeing a big space anywhere in that vicinity. Maybe it's browser-specific. (I'm using Firefox.) Could you post a screenshot? — Eru·tuon 02:18, 30 August 2019 (UTC)

@Erutuon: uploaded the issue. Will consider switching to Firefox eventually... ～ POKéTalker（═◉═） 07:43, 30 August 2019 (UTC)

I con confirm the bad layout in both IE and Edge, but not in Chrome or Firefox. I think this may be a matter of Microsoft's non-support of modern web standards.

(Incidentally, @POKéTalker, I think the 渦巻銀河 spelling all in kanji is more common, and should probably be the lemma. Compare hit counts for google:"渦巻銀河" (206K), google:"渦巻き銀河" (62K), google:"うずまき銀河" (5.8K), google:"渦まき銀河" (288). Lower numbers, but roughly similar proportions, for hit counts on Google Books as well.) ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:38, 30 August 2019 (UTC)

Idea about consolidating spelling-related data

@Dine2016, anyone else interested:

The updates to this template to include alternative spellings has worked out quite well, I think.

1. I wonder if this template should also be updated to include the historical kyūjitai spellings? For entries with multiple POS sections, we currently have to duplicate the kyu=... param and data in each POS template call, which is awkward and inefficient.
2. I wonder too if the historical kana spellings should go here as well? These currently must also be duplicated in each POS template call.

Curious about your thoughts. ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:07, 25 September 2019 (UTC)

@Eirikr: I'm glad you asked. The headword templates are definitely not suitable for placing kyūjitai, and {{ja-kanjitab}} is a better place for them. However, I'm not sure whether historical kana spellings should be placed in {{ja-kanjitab}} or in the pronunciation section. If we place them in {{ja-kanjitab}}, then the primary function of {{ja-kanjitab}} becomes to show alternative spellings of the term, not to show the kanji in the current spelling, and {{ja-spellings}} does a better job.

As for kyūjitai: First, a term may have several kyūjitai forms. For example, the kyūjitai of 弁明 can be either 辯明 or 辨明, but they are still considered as one entry. Second, a character can have several kyūjitai forms. For example, the kyūjitai of 画 is usually held to be 畫, but its variant form 畵 is also seen in pre-WWII publications. Third, spellings may have varying degrees of "kyū"-ness. For example, the term for "lantern" can be either 灯籠, 灯篭, 燈籠 or 燈篭. It's hard to say which is shinjitai and which is kyūjitai depending on which shinjitai standard you're referring to. Finally, the character set you're using may affect how "kyū" you're going. For example, within the JIS X standards the kyūjitai of 国産 is 國産, but Unicode allows you to type 國產 which is closer to pre-WWII 印刷字体. You can even get more by using 異体字セレクタ, though it's not supported on every browser (and we may have to use images as a fallback). Given these issues, I think properly supporting kyūjitai may be a lot of work, and must be carried out by people more knowledgeable than I (such as Suzukaze-c). --Dine2016 (talk) 16:09, 26 September 2019 (UTC)

@Eirikr By the way, since you have realized that duplicating data in each POS template call is awkward and inefficient, what about removing alternative scripts completely, like this?

{{ja-kanjitab|は|yomi=o}}

===Pronunciation===
{{ja-pron|は|hhira=は}}

===Affix===
{{ja-affix}}

# to [[separate]]
# [[faction]]; [[group]]; [[clique]]; [[wing]]; [[school]]
# to [[dispatch]]; to [[deploy]]

===Noun===
{{ja-noun}}

# [[faction]]; [[group]]; [[clique]]; [[wing]]; [[school]]

This format would be more orthogonal, though it would be more logical to subordinate POS to senses for one-kanji kango:

{{ja-kanjitab|は|yomi=o}}

===Pronunciation===
{{ja-pron|は|hhira=は}}

===Definitions===
{{ja-kango}}

# to [[separate]] {{ja-pos|affix}}
# [[faction]]; [[group]]; [[clique]]; [[wing]]; [[school]] {{ja-pos|affix|noun}}
# to [[dispatch]]; to [[deploy]] {{ja-pos|affix}}

--Dine2016 (talk) 14:13, 27 September 2019 (UTC)

@Dine2016:

• I'm not sure what you mean by "removing alternative scripts completely". I'm intrigued, but confused.
• Your example on the bottom strikes me as potentially problematic. Certain senses are specific to the affix sense and are not shared by the noun sense. This also obscures usage -- a noun is usable as a standalone word with particles following, whereas an affix is only usable as part of a larger compound word. If we only use a "Definitions" header, we lose that important information, and users might be misled into thinking that this word could be used as a verb, or as a noun with a gerund-like meaning relating to the verbal sense lines. Japanese is not as flexible in that regard, as compared to Chinese.

‑‑ Eiríkr Útlendi │^{Tala við mig} 23:13, 27 September 2019 (UTC)

@Eirikr: By "removing alternative scripts completely" I meant moving the reading to the pronunciation section.

As for the second question, POS information is shown by labels to the right of the definitions. This results in a cleaner format both for the editor and for the reader. It also eases maintenance. Suppose an editor finds out that the “faction; group; clique; wing; school” sense can also be a suffix. With the current format, they would need to add the following at best:

===Suffix===
{{ja-suffix}}

# [[faction]]; [[group]]; [[clique]]; [[wing]]; [[school]]

With the format I propose, they only need to add a "suffix" to the POS label.

(Using {{ja-pos}} as the name of the new label template was a mistake because that name was already used.) --Dine2016 (talk) 02:01, 28 September 2019 (UTC)

• <nods/> I think I understand better what you're thinking. Gaining approval from other editors may be difficult; resistance to the major shift in Chinese entry structure away from POS headings was partly alleviated by the clear and understandable argument that Chinese doesn't really have POSes, not like in other languages -- any given word could be used umpteen different ways, depending on context, so POS headings are effectively arbitrary. Not so for Japanese, however.

Query: How do you propose to order senses in this new format? By frequency? How would that be measured? Current practice is sense-agnostic, and simply alphabetizes the order of sections based on POS heading.

Suggestion: Put the POS labels in front. This is consistent with other labeling that goes at the front of the line, and it conforms to similar formatting in other dictionaries I've seen that put POS info inline. When doing so, it would probably make sense to format the POS labels in some way that is distinct from the {{lb}} labels, perhaps by using bold and linking through to the relevant entry in Appendix:Glossary, or to the relevant main term entry if that term is missing from the Glossary.

‑‑ Eiríkr Útlendi │^{Tala við mig} 18:19, 14 October 2019 (UTC)

@Eirikr: "Not so for Japanese, however." No for Japanese in general. But one-kanji kango have more flexible POS. For example, consider one-kanji kango that can be used as a noun, such as 円 (en) and 陽 (yō). The noun senses are usually a subset of the affix senses. If we divide the senses by POS, we will have to duplicate some of the senses (“yen; circle” and “yang; open/overt/visible space”) under both Noun and Affix. If we instead use the Definitions header and give POS information as labels, we can reduce repetition. --Dine2016 (talk) 04:20, 15 October 2019 (UTC)

• Re: "By "removing alternative scripts completely" I meant moving the reading to the pronunciation section." --

Hmm. Non-duplication is good, and I definitely like the way that simplifies the entry. But historical kana spellings are not part of pronunciation, and haven't been for a very long time, given the roughly Heian-era ハ行転呼 shift and other sound shifts through history.

For Japanese in particular, given the interestingly wide gap between spoken and written forms, we almost need a ===Spellings=== section. ===Pronunciation=== is about how to say it, so ===Spellings=== would be about how to write it. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:51, 14 October 2019 (UTC)

@Eirikr: Another solution, which can be found on my user page, is to treat spellings and pronunciation separately. See the ":)" box on my user page for an example. --Dine2016 (talk) 04:20, 15 October 2019 (UTC)

@Dine2016: FWIW, I like that :) example very much. ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:15, 15 October 2019 (UTC)

Sense-specific alts?

@Dine2016: I ran into a difficulty in correlating ノット and 浬. The etym for ノット is just English knot, but the kanji spellings are only alts for the speed-related sense. Any advice on how to proceed? Splitting out the etym at ノット is one option, one for the nautical speed sense and one for the knot in a string sense, but we generally don't list separate etyms for separate senses when the etymon is the same thing. ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:43, 2 December 2019 (UTC)

You mentioned using {{ja-def}}. I've never seen {{ja-def}} used to link to the same entry it's used on. The template documentation is a bit minimal, but I'd always understood it as intended for use in soft-redirects. "Redirecting" from ノット to ノット never would have occurred to me.

I don't suppose you might have a less-confusing approach? ‑‑ Eiríkr Útlendi │^{Tala við mig} 04:32, 3 December 2019 (UTC)

@Eirikr: {{ja-def}} is no longer used for soft-redirection. It is now used to provide an alternative list of kanji spellings if it is different from the word-level kanji spelling list in the |alt= parameter of {{ja-kanjitab}}, as exhibited at 貴方.

As for why ノット must be included in this case, the answer is that sense 2 would have no {{ja-def}} if we don't include ノット. By default, no {{ja-def}} means "this sense has no spelling requirements so all spellings apply to it", rather than "this sense cannot be spelled in kanji". So I added ノット temporarily. Eventually we should have some way to mark a spelling as kana-only (either with something like ja-uk, or with a zero-argument {{ja-def}}).

Again, pushing for changes to the Japanese entry layout is slow, so I suggest moving to EDICT :) They have a working solution to restrict spellings to senses --Dine2016 (talk) 06:22, 3 December 2019 (UTC)

@Eirikr I made {{ja-see}} ignore definitions containing the comment <!-- kana only -->. See this diff and the correctly-working 浬. But I wonder if this annotation should be available to the user as well as {{ja-see}}. --Dine2016 (talk) 04:52, 15 January 2020 (UTC)

Improved presentation of kun readings and okurigana?

In its current form, most entries for terms with okurigana have kanjitabs which pretend the okurigana don't exist. For exammple: 来る has {{ja-kanjitab|く|yomi=kun}} which also adds the page to the category "Japanese terms spelled with 来 read as く". This presentation and categorization is technically incorrect. Okurigana are part of the reading, and are not superfluous. If a user goes to 来 looking for a reading of く they won't find it, because it isn't there, because く is not a reading of 来, く-る is.

The documentation for kanjitab is of no help on this matter. None of the examples show how terms with okurigana should be represented, there's only a reference to their omission and the use of the sort key.

— 173.71.89.57 22:19, 2 March 2021 (UTC)

The kanjitab presentation is intended to indicate how the kanji portion is read. By definition and intent, this does not include okurigana.

We understand that okurigana are not superfluous to understanding the terms. However, for purposes of reading, we seek to clarify which morae are included in the kanji itself, as shown in the kanjitab and the categories, and which must be spelled out separately as okurigana, as shown in the entries themselves.

In your example, if a user goes to 来#Japanese, they will see the list of readings there at the top of the entry, which includes く for the kanji portion:

くる (kuru, 来る, Jōyō)

This links through to the kana entry at くる#Japanese, the kanji + okurigana entry at 来る#Japanese, and clearly shows the kanji and okurigana. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:58, 3 March 2021 (UTC)

Bug in appendices

The kyujitai altspelling box such as in one appendix entry here gives out the whole page name rather than the kanji compound. Anyone willing to fix this? ～ POKéTalker（═◉═） 06:31, 20 April 2022 (UTC)

Removing jūbakoyomi and yutōyomi as inputs

I'd like to remove these from the list of yomi types that can be specified, for a couple of reasons:

1. They discourage people from being more specific about which kind of on'yomi it is: e.g. goon/kun or kun/kan'on are both more specific, and at worst people would enter on/kun or kun/on, which is no worse.
2. I don't think they're necessary most of the time, as it's possible to determine these based on the inputs: if it's a two-kanji term, it's just a matter of checking whether it fits either pattern, and this process is already automated when a term contains exactly two kanji anyway. I appreciate that automation might not be fully possible, since some terms with two kanji + kana may qualify, while others won't (e.g. when part of a larger compound), so we may want to have a manual flag for those situations; maybe pattern=? However, it shouldn't be needed most of the time (and indeed most terms in Category:Japanese terms read with jūbakoyomi and Category:Japanese terms read with yutōyomi have been put there by automatic determination already).

Pinging @Eirikr @Lattermint @Fishbowl @Poketalker Theknightwho (talk) 09:11, 3 July 2024 (UTC)

Agreed that jūbako / yutō are not needed as inputs, and that we should remove these as options. I've also had to fix instances where other editors have entered these mistakenly, such as for words with more than two kanji.

Categorization already works automatically, as you've noted.

I don't see any negatives from removing these as input options, and doing so would indeed encourage editors to be more specific with the reading types. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:04, 5 July 2024 (UTC)

煮頃鮒

煮頃鮒 shows an "Alternative spelling" as the kyuujitai of itself. Perhaps this is a bug. Shlyst (talk) 17:43, 28 November 2024 (UTC)

Other words that do this:

復水器

蓄電器 Shlyst (talk) 18:04, 28 November 2024 (UTC)