Module talk:kanjitab

.kanji-table

@Erutuon Korean and Vietnamese use nearly-identical templates ({{ko-hanjatab}} and {{vi-hantutab}}). I would support a general CSS class to consistently style all of these at once (maybe even a single module??), but maybe the name should be less Japan-centric. —suzukaze (t・c) 23:10, 22 August 2017 (UTC)

@Suzukaze-c: Oh, that makes sense. Perhaps .Han-character-table or .Han-char-table? I'm sort of hesitant to put the styles in MediaWiki:Common.css, because then they won't be used in the mobile site, but it's a general problem, not just affecting this. — Eru·tuon 23:18, 22 August 2017 (UTC)

Jukujikun

Should we add 熟(じゅく)字(じ)訓(くん) (jukujikun) to the list of yomi types? It would be useful, even if we replace some nonspecific "irregular" classifications by giving yomi types for the individual characters as in Module:User:Suzukaze-c/Hani-tab. — Eru·tuon 20:48, 27 August 2017 (UTC)

Nanori

Wondering if it would be possible to add a nanori category. There's an IP anon obsessed with names right now.

On the other hand, given the broad leeway granted for nanori readings, perhaps this is an awful idea? What do others think? ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:56, 20 August 2018 (UTC)

class="floatright" (diff)

@Dine2016: FYI, User:Eirikr didn't like class="floatright" ([1]). —Suzukaze-c◇◇ 03:16, 28 February 2019 (UTC)

@Suzukaze-c: Ah, thanks for the precious information. I changed {{ja-spellings}} and {{ja-kanjitab}} to class="floatright" because they would be laid out horizontally, with no space between, were they both style="float: right". Do you know any way out? --Dine2016 (talk) 06:30, 28 February 2019 (UTC)

Perhaps we could add inline style="clear: none;", or add .kanji-table.floatright { clear: none; } to Template:ja-kanjitab/style.css. —Suzukaze-c◇◇ 06:03, 1 March 2019 (UTC)

• Heya @Suzukaze-c, Dine2016, saw some screwy layouts on various pages and came to the module trying to figure out what happened. I just changed class="floatright" back to style="float:right;" for now so at least existing pages aren't a mess. Horizontal layout is actually expected and desired in some cases, so I'm not sure what the problem was? ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:36, 18 April 2019 (UTC)

@Eirikr: Thanks for your follow-up. What are the screwy layouts caused by class="floatright"? Quite the contrary, I think every box on the right should use class="floatright" so that they all stack vertically. If we're to allow some of them to lay horizontally, (1) it may not work well on smaller screens, where space for a portion of the text will be too narrow, maybe just enough for one or two words per line, and (2) you need manual instructions to get them lay vertically, and putting layout instructions into mainspace entries is a bad idea, as bad as embedding CSS into logical HTML, or JSP model 1 architecture. I think we should universally employ class="floatright" and code the CSS to determine which box combinations are laid horizontally and which are stacked vertically.

By the way, 藍 seems to have too many boxes. I think we can remove the wikipedia boxes and put the links in a "See also" or "Further Reading" section. (Can I move the entry to あい? I would like to have the rule of “which spelling of lemmatize at” written into WT:AJA before actually moving entries.) --Dine2016 (talk) 03:05, 19 April 2019 (UTC)

• Prior to CSS changes that have occurred somewhere in the past several months, the PC browser layout was similar to what I see currently after reverting to style="float: right;", for those entries that have WP boxes and images as well as {{ja-kanjitab}}: on the right in a visual column of 250px plus padding, the WP boxes happen first, then the image(s). Just to the left at the same vertical location as the WP boxes, we see {{ja-kanjitab}}. This layout makes good use of screen real estate, and is visually pleasing as {{ja-kanjitab}} is roughly the same height as the JA and EN WP boxes together (this fit together better before the addition to {{ja-kanjitab}} of 1em of padding top and bottom).

As examples, please view 漫画, 猿 (where we see Fumiko's aggressive replacement of {{wp}} with {{swp}}), 恐竜, etc. All look visually better on a PC when using the style as opposed to the class, whereas the style and the class approaches look roughly the same on mobile.

When viewed on my iPhone, all three entries exhibit a graceful shift to showing the WP boxes, the image, and then {{ja-kanjitab}}, followed by the rest of the entry content -- effectively the same layout of sidebar stuff as what class="floatright" was enforcing, only then in all cases and not just on mobile.

If we're not optimizing just for mobile, and if we have horizontal screen real estate -- which we do for regular computer-based browsing -- we should make use of that horizontal real estate.

As an extreme example, see 桜. That has a lot of images, which I believe add to the entry and illustrate the various senses. Stacking everything vertically in a single column would result in a ridiculously long entry, for no good reason -- where we have horizontal real estate, we should use it.

I hope that helps explain my position. ‑‑ Eiríkr Útlendi │^{Tala við mig} 03:45, 19 April 2019 (UTC)

OK, I understood. Withdrawing. (By the way, I really hope collapsing can work in mobile view. Reading Chinese entries on my phone is a pain due to having to skip large portions of pronunciation section to arrive at the definition.)

By the way, I think 桜 look better when words are cited in the format 桜色 (さくらいろ, sakura-iro) instead of 桜色 (sakura-iro). As a Chinese I can immediately grasp the reading upon seeing kana, while romaji requires a greater effort to read. --Dine2016 (talk) 04:53, 19 April 2019 (UTC)

|alt=

@Dine2016: This parameter is not covered by Template:ja-kanjitab/documentation. Also, it may need a label system since there may be some archaic/obsolete/rare alternatives. ᾨδή (talk) 18:54, 9 October 2019 (UTC)

@ᾨδή: Thanks, but I don't know how to do it right. {{ja-kanjitab}} needs a way to handle kyūjitai and a way to distinguish modern and historical kana as well. --Dine2016 (talk) 07:49, 13 October 2019 (UTC)

@Dine2016: First please add the information for |alt= to Template:ja-kanjitab/documentation. It needs a description there anyway. As for the label issue, you can try some solution like this:

{{ja-kanjitab|alt=ハハハ,ははは,ははハ|alt_lb=obsolete,,rare}}

Or alternatively, cease using |alt= all together and fall back to use the old ===Alternatvie forms===. ᾨδή (talk) 09:58, 13 October 2019 (UTC)

• Re: documentation, agreed that we should write something. Any of us could do it. I may have a poke at it later today.
• Re: implementation, please don't abandon this and revert to using a separate ===Alternative forms=== section.  :) I think the alt functionality of {{ja-kanjitab}} is a big improvement -- it's smaller, it's less obtrusive and makes effective use of screen real estate, it keeps character information in one place rather than scattered about the entry, and this feature is further leveraged by {{ja-see}} (and maybe also {{ja-see-kango}}?) when used in other entries that point to the one with the alt info. This alt feature also allows us to specify alternative forms, and have that similarly leveraged from other entries, in purely kana entries. See マテガイ (mategai) as one such example, where the katakana spelling is the lemma, and there are three alternative kanji spellings (that I know of, possibly more).

If labeling proves overly difficult to incorporate directly into {{ja-kanjitab}}, I'm not sure we really need it in the template -- that kind of usage information can go on the entries for those alternative forms. Similarly, see the kanji spellings for mategai, where I included info about the spellings themselves under the ===Etymology=== header and just before {{ja-see}}.

That said, I like ᾨδή's suggestion of including labels in the template, if that can be done. The labels could ideally be reflected in the output of {{ja-see}}, so that the current output (for example):

(This term, 蟶貝, is a kanji spelling of マテガイ.)

... would output instead:

(This term, 蟶貝, is a rare kanji spelling of マテガイ.)

... or instead of "rare", whatever other label has been specified in the {{ja-kanjitab}} params on the targeted page.

As an implementation suggestion, I don't like having the alts in one param and the labels in another -- this is poor usability, as it requires slightly hacky empty values, and it requires the editor to match up positional arguments in two separate params in a confusing and error-prone fashion. Since the module code is already parsing the alt string to split on commas, what about having a second parsing pass on the resulting individual alt values to split out alt spellings from labels? This could allow something like the following, which is easier on editors as it keeps the alt spellings and labels together:

{{ja-kanjitab|alt=ハハハ obsolete,ははは,ははハ rare}}

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

@Eirikr: Is there any altform that actually contains a space character? ᾨδή (talk) 08:43, 16 October 2019 (UTC)

• @ᾨδή: A good question. I don't think so, as JA lemmata should never have any spaces in them -- spaces only appear in our wikicode if we're denoting word breaks for things like {{ja-r}}. Since {{ja-kanjitab}} doesn't do any ruby for alt forms, there's no reason for editors to insert spaces.

If there are edge cases that I'm just not aware of at the moment, an alternative would be to use some other non-whitespace character as the divider between the target term and the label. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:32, 16 October 2019 (UTC)

• It looks like @Dine2016 already added a brief description. Thank you! ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:09, 14 October 2019 (UTC)

@Eirikr: If we want the labels to be reflected in the non-lemma entries we need to restrict the kind of labels available, to produce grammatically correct descriptions in the bottom of {{ja-see}}. If we allow arbitrary labels, it may be difficult to determine whether to use "a" or "an"; also, longer phrases may look strange if simply inserted like "This term, xxx, is a used during Meiji period spelling of ...". It might be better to provide only a simple set of labels like "obsolete/archaic/rare/...", and leave the longer descriptions to the Etymology or Usage notes sections.

I completely gave up hope of improving the Japanese entry layout of Wiktionary because of the difficulty of pushing for changes. For now, I'm more happy with the design of EDICT/JMdict and will probably contribute there. --Dine2016 (talk) 03:59, 15 October 2019 (UTC)

@Dine2016:

Re: the labels, yes, agreed. Only certain ones even make sense in this context, even aside from the issue of encoding the grammar. Limited would be the way to go.

Re: moving on -- Well, I'd hate to lose you, as you've been extremely helpful with your coding and changes in infrastructure, and I very much appreciate your different ideas about layout and functionality. That said, I understand that it can be frustrating here, and I'll respect whatever decision you ultimately make. Thank you, sincerely and greatly, for your contributions! ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:10, 15 October 2019 (UTC)

categorization of 綴り字発音

@Huhu9001 I don't see what's wrong with |yomi=y2,o2, since 綴り字 by itself would be |yomi=y. —Suzukaze-c (talk) 01:52, 6 November 2021 (UTC)

@Suzukaze-c: It adds the whole entry 綴り字発音 to cat:Japanese terms read with yutōyomi.

Besides, it is almost always better to use |yomi=k,o than |yomi=y. Whether a word is yutōyomi is of little significance in Japanese since it does not affect the meaning, pronunciation, or grammar. Practically, for those who know what yutōyomi is, you don't need to tell them as they readily recognize yutōyomi upon seeing |yomi=k,o, and for those who don't, the notation yutōyomi only confuses them. Furthermore, you can specify kan'on, go'on, etc. with |yomi=k,o, but not |yomi=y.

In my opinion, keeping yutōyomi and jūbakoyomi‎ only in the two categories cat:Japanese terms read with yutōyomi and cat:Japanese terms read with jūbakoyomi is already enough. -- Huhu9001 (talk) 07:46, 6 November 2021 (UTC)

That's fair. I wouldn't disagree with removal of |yomi=k and |yomi=j, actually. —Suzukaze-c (talk) 02:11, 7 November 2021 (UTC)

Kyūjitai font-size

Although I can't find documentation any rationale for the 140% font-size, I will defend it as being a good idea: the kyūjitai form is liable to have delicate differences that are more readily visible at larger sizes. —Fish bowl (talk) 01:46, 11 July 2024 (UTC)