Template talk:Han char

Template for Han character section
This is used under the Han character header, in the Translingual section of the entry for a single Han character, which precedes the language sections. It adds the character to Category:Han characters in radical/stroke sort order (then by Unicode order).

Usage:

All parameters are named:


 * alt= alternate form(s)
 * rad= single character radical
 * rn= radical number
 * as= additional strokes. This must be a two digit number for the radical/stroke sorting to work in Category:Han characters! So 3 additional strokes is "03".
 * asj=additional strokes in Japanese
 * sn= total strokes. Three here is "3", not "03".
 * snj= total strokes in Japanese
 * so= stroke order, image width should be 40px times the number of characters shown, no caption
 * four= four corner system (format 1234, 12345 or 1234.5, multivalue separated by comma)
 * canj= Cangjie input (A-Y only, multivalue separated by comma)
 * ids= IDS composition sequence (multivalue separated by comma, regional annotation allowed)
 * gso= graphical significance and origin
 * cmean= common meaning

Expanded
The suggested expansion, for linking to the Commons category, is now inserted. For the details, see the documentation of &#123;{Han rad}}.

A large number of transclusions happen with insufficient parameters. To find and repair them, the contained maintenance category Category:Chinese terms needing attention is expanded too, and provided with the pages in error and their error type (a, n, q, s); for the details, see the category. Of course, the category should always kept empty. -- sarang &#x2665; 사랑 16:47, 24 April 2012 (UTC)

Characters with multiple possible IDS descriptions
There seems to be characters that can have different representations in IDS due to Han unification (like 蝉 (G:⿰虫单 J, K:⿰虫単) or 㪌 (G, K:⿰甬攴 T:⿰甬攵)). Is there a way to handle this? (Is this the right place to discuss this?) —umbreon 126 06:59, 8 November 2014 (UTC)


 * Now supporting multiple value in four-corner and composition. You can put it like
 *  ids=⿰虫单(G),⿰虫単(JK) 
 *  ids=⿰虫单 (G) ,⿰虫単 (JK) 
 * in one parameter (as I did 倩 earlier). Links are generated on only component characters; others are ignored. --Octahedron80 (talk) 23:36, 11 December 2015 (UTC)


 * Neat. However, maybe it would be better to use  instead of , because   is for subscript text, and (G) has no reason to be subscript. —suzukaze (t・c) 07:25, 12 December 2015 (UTC)
 * Let's follow that. Use small instead of sub. --Octahedron80 (talk) 07:28, 12 December 2015 (UTC)

I wrote about regional annotation at the above section. --Octahedron80 (talk) 04:11, 8 January 2016 (UTC)

Invalid parameter
𠕇 has been put in the hidden. What's wrong with it? Justinrleung (talk) 06:11, 7 October 2015 (UTC)
 * is picky; if there are less than ten strokes then the number must start with zero. (IMO I find it bizarre that the template can detect this but it can't automatically add the zero itself) —suzukaze (t・c) 06:16, 7 October 2015 (UTC)

Add Zhengma to the template?
I noticed that this template already has parameters for Cangjie and the four-corner method. But could we and should we add a parameter for the ? - VulpesVulpes42 (talk) 18:48, 4 November 2015 (UTC)
 * There is no Zhengma data (or something similar) in Unihan database. If it's possible, where could we get the data from? I don't recommend to manually input because there are ten thousands of Han characters to say.--Octahedron80 (talk) 09:44, 7 December 2015 (UTC)


 * zdic.net has zhengma data for most characters, in fact, if you look up a character at zdic.net, you are more likely to find how to input the character using zhengma than how to input it using cangjie. Most likely because cangjie does not have an input for those characters. VulpesVulpes42 (talk) 16:24, 28 December 2015 (UTC)
 * I am looking for the raw database of zhengma, like tabular data, if it is available to be imported by bot. And it can be used in index pages either. Editing this template is just easy. --Octahedron80 (talk) 06:25, 7 January 2016 (UTC)
 * There are multiple input tables available online that can be rather easily "mined" for codes for most characters (rime input tables are tab-separated). The only challenge might be dealing with alternative codes where more than one is available, as well as Simplified First/Traditional First division. For example in the Traditional First tables, 見 has the code lr，and 见 has the code lra. Those codes are reversed in Simplified First tables (i.e. lr = 见 and lra = 見). --Mea Gratia (talk) 21:00, 5 September 2020 (UTC)
 * If possible, it would be nice to reignite this discussion and see if it is possible to go forwards with adding zhengma codes. Zgw3kszo (talk) 21:16, 25 February 2024 (UTC)

I have a question: if there are more input method references in the future, is it suitable to include them in one line? --Octahedron80 (talk) 06:00, 1 February 2016 (UTC)

Font (language) used in translingual section
Hello. Which font (language) is implied in the translingual section? Ideally I would say it should be the Kangxi form, but I do not know even if there is a technical mean to display the Kangxi form. Thank you!! --Maidodo (talk) 12:34, 8 May 2016 (UTC)


 * It seems like it is PRC-style Chinese. I like the idea of using Kangxi forms, but I don't think it is feasible. —suzukaze (t・c) 22:58, 8 May 2016 (UTC)

Multiple Cangjie support
There can also be multiple Cangjie versions for one character, see 螤|here. --Sarefo (talk) 12:04, 11 June 2016 (UTC)

rn (radical number)
We don't need this, do we. It can be determined from rad. —Suzukaze-c◇◇ 01:45, 15 March 2020 (UTC)

Additional/total strokes options
I'm wondering why there isn't an option for |as=(traditional Chinese and Japanese) and |asck=(simplified Chinese and Korean). Or if there is, it's not listed.

Also, the table for this section was a bit unclear to me at first, as I had thought that there were two columns each describing separate parameters. But in reality, there is only one column describing the two parameters in tandem. Perhaps it could be clarified that |as is always present but changes depending on the second parameter. There could be darker borders between the rows to help signify that each row is a pair together, but I'm not sure how to edit to table to show that. ChromeGames923 (talk) 06:26, 20 April 2021 (UTC)

Support for negative values for as?
Some Han characters consist of a deletion of stroke from a radical, for example 王 w.r.t. 玉 and the variant radical 扌 w.r.t. 手. Could support for negative values for the additional strokes parameter be added? On the page for 王, you can see that someone has entered -1 for as, but it displays as "玉+-1"

173.72.124.197 21:27, 30 July 2021 (UTC)

Three or more stroke parameters
Hi, I notice you've worked on this template in the past so I'm wondering if you can help with the formatting of the stroke counts. Currently it somewhat breaks when there's more than two different stroke count parameters. For example, 著 produces "12 strokes in Chinese in traditional Chinese" when it should just say "12 strokes in traditional Chinese".

Even worse is the page I just edited, 蘭. With the parameters "|sn=21|snm=20|snj=19|snk=21", it produces "21 strokes in Chinese in Chinese in traditional Chinese, 21 strokes in Korean..." Alternatively with the parameters "|sn=21|snm=20|snj+=19" it produces "21 strokes in Chinese and Korean in traditional Chinese..." Ideally it would say "21 strokes in traditional Chinese and Korean" but an acceptable middle ground would "21 strokes in traditional Chinese, 21 strokes in Korean". As long as it doesn't keep saying "in Chinese" or mix up Korean with (traditional) Chinese, that would be much better. Is there any solution to this or a fix that can be done to the template? Thanks, ChromeGames923 (talk) 08:11, 3 September 2021 (UTC)
 * The system of stroke number parameters described in and the accompanying code in Module:zh-han (which I rewrote at one point) was designed for cases where there are one or two stroke numbers, but it's not clear to me how it's supposed to work with three or more stroke numbers. For the cases you give it needs two steps: figure out which language system (Chinese, traditional Chinese, Japanese, etc.) has which stroke number, then format it. The first step requires interpreting what each of the explicit parameters, snm, snj+ mean and then figuring out what sn means based on that. I'm not sure what sn means in each case you give, particularly in the case with 19 (though I could try to guess), because the template documentation only explains what sn means when there is just one other stroke parameter. It would be much clearer, and easier to write code for in Module:zh-han, if there were only sns (Simplified Chinese), snt (Traditional Chinese), snj (Japanese), snk (Korean), and whatever else, and you had to write all of them when they have the same stroke number. However, that would be less convenient.
 * Anyway, if you can clarify what  and   mean, in terms of "Traditional Chinese has 21 strokes, Simplified Chinese has 19 strokes, ...", then I or someone else could decide how Module:zh-han would best implement this. Or perhaps it would be better use the clearer system of parameters (no plain sn) when there are three or more stroke numbers. — Eru·tuon 19:09, 3 September 2021 (UTC)
 * The expected behavior isn't clear to me either in the case of three or more stroke parameters; I've seen a few pages that say "in Chinese in traditional Chinese" and at first I thought it was intentional. I'm not sure if there's a clean definition of 19 either, I only mentioned it because I was trying different combinations with +, and that one just happened to produce a close result. But 19 was confusing to me so I ultimately decided not to use it when I saved my edit.


 * Within the current system of using sn with four main script styles (traditional, simplified/mainland, Japanese, Korean), I can think of having sn automatically adapt to the other parameters when there are more than two parameters. For example, if there are three different parameters (sn plus two others) and:


 * the other two are Japanese and Korean, then sn could say "Chinese"
 * the others are simplified/mainland and Japanese/Korean, then sn could say "traditional Chinese"
 * the others are simplified/mainland and Japanese/Korean, and there is a "+" sign somewhere, then sn could say "traditional Chinese and [Korean/Japanese]", whichever of Korean or Japanese wasn't defined manually.
 * In the case of four numbers, sn should probably be "traditional Chinese" since everything else would already be specified. This is definitely messier than the current system and a bit confusing, but I think it probably wouldn't break anything that's currently working.


 * As for a system with no sn, this does seem like it would be clearer in behavior (actually that idea is kind of how I wrote 蘭 right now). It might be helpful to have as an alternative to the current system, so that way everything doesn't have to be changed and the more convenient way is still available. But even with the current format, there are some options missing: earlier on this talk page I mentioned how I wanted to use snck or snck+, though I don't remember which character I was talking about. Those two could probably be added to the template without much difficulty, but having the alternative system would be able to handle everything flexibly without having to code in new combinations (for example if there are differences between Hong Kong and Taiwan that aren't already covered). I realize though that it's probably a lot amount of work for something that'll be used quite rarely, so it might not be worthwhile. ChromeGames923 (talk) 20:25, 3 September 2021 (UTC)

idea for treatment of regional standard forms
instead of having convoluted parameters like "asm++", why not have multiple headword templates, marked with Mainland China or sth, and additionally display the correct form using appropriate language codes like "zh-CN"? —Fish bowl (talk) 00:14, 7 March 2023 (UTC)