Template talk:zh-see

Simplified to traditional

When redirecting from a simplified to a traditional form, I rather think the autocollapsed portion should simply be shown to the user without their needing to click [Expand]; after all, any user who goes to a simplified form without realising there will not necessarily know that information. What think you, Wyang? —Μετάknowledge^{discuss/deeds} 06:31, 31 March 2015 (UTC)

(Notifying Kc kennylau, Atitarev, Tooironic, Jamesjiao, Bumm13, Meihouwang): I don't have a strong preference in this, so any format would be fine. Also since we are here, the width of the table seems to warrant an increase as it appears multilined when viewed on a Macbook's Chrome using Tabbed Languages. Wyang (talk) 07:05, 31 March 2015 (UTC)

Expanded is better, IMO. No opinion on the width--Anatoli T. ^{(обсудить}/^вклад) 08:19, 31 March 2015 (UTC)

I agree expanded is better. But even more better would be including an auto-redirect for all simplified entries that do not already include JKV readings. Let's think about the majority of Chinese speakers in the world who use simplified on a daily basis and not traditional. ---> Tooironic (talk) 09:50, 31 March 2015 (UTC)

I oppose converting to hard redirects. They lack categorisations and for consistency with other entries. We may get a different solution in the future where simplified entries display the contents of traditional entries. Users could live with a single inconvenience - an additional click to get to traditional entries but (regular) users familiar with our setup will choose traditional in the first place. No dictionary (book, electronic or online) ever duplicates contents for each character set, it just happens that traditional is chosen over simplified here. --Anatoli T. ^{(обсудить}/^вклад) 03:06, 1 April 2015 (UTC)

As long as it looks ok on mobile devices :). That's my only concern. Jamesjiao → ^{T ◊ C} 22:07, 7 April 2015 (UTC)

line 29 of Module:zh-see

width:' .. (70 + mw.ustring.len(title) * 3) .. '%

↑ It looks like this needs to be revised because on 大鱼吃小鱼，小鱼吃虾米, comes out to be 103%. (perhaps min-width:70% would be better...?) @Wyang? —suzukaze (t・c) 22:35, 7 June 2015 (UTC)

I'm not sure familiar with formatting tricks such as these... Wyang (talk) 01:02, 20 June 2015 (UTC)

module error in 观测

When I go to 观测 I see a module error. The exact message: "Script error: The module returned a value. It is supposed to return an export table." At first I thought some bot broke it, but it turns out this error doesn't exist when I look at the article in preview mode. No previous versions, and neither the current version, show the error when looking at it in preview mode. What's going on? Is there something wrong on my side? 汤玛斯 (talk) 12:02, 27 August 2015 (UTC)

Something else was broken: [1]. Wyang (talk) 10:50, 28 August 2015 (UTC)

不可胜计

[[Category:Chinese simplified forms|一03不可胜计]][[Category:Chinese lemmas|bu4ke勝ji43,nc=non2stan5dar5d5in5main5lan5d5]][[Category:Mandarin lemmas|bu4ke勝ji43,nc=non2stan5dar5d5in5main5lan5d5]][[Category:Cantonese lemmas|non-standard in Mainland]][[Category:Chinese idioms|bu4ke勝ji43,nc=non2stan5dar5d5in5main5lan5d5]][[Category:Mandarin idioms|bu4ke勝ji43,nc=non2stan5dar5d5in5main5lan5d5]][[Category:Cantonese idioms|non-standard in Mainland]][[Category:Chinese terms with IPA pronunciation|bu4ke勝ji43,nc=non2stan5dar5d5in5main5lan5d5]]

This can't be right—suzukaze (t・c) 08:06, 9 September 2015 (UTC)

花里胡哨

is being sorted into "Gan lemmas/idioms" for some reason. —suzukaze (t・c) 05:08, 7 October 2016 (UTC)

Fixed. Wyang (talk) 23:33, 7 October 2016 (UTC)

"av" vs. "a"

@Wyang, Suzukaze-c, what's the difference between these two? If it's ancient, isn't it automatically a variant? — justin(r)leung _{{ (t...) | c=› }} 05:05, 10 September 2017 (UTC)

My worst fear... it was in fact me who added it in. I can't recall why I did that, but looking at my edits around then, it seems to be this edit that prompted me to do so (to clarify "variant"). I think it should be merged with 'ancient' into a, with perhaps the default display of "ancient variant". (entries using av) Wyang (talk) 05:14, 10 September 2017 (UTC)

More thoughts on this: perhaps the distinction between "ancient/ancient variant" could be whether the glyph was the predominant form in ancient writings. If so, it is "ancient", otherwise it is "ancient variant". Whether this distinction is worth keeping is open to question - it's a bit difficult to verify whether a form was predominant or less common in many cases. Wyang (talk) 05:20, 10 September 2017 (UTC)

variant types

How do variant types in hanzi dictionaries like 同×, 通×, 初文, 古字, 本字, 俗字, 篆字, 略字, etc., translate to {{zh-see}} code? I've been using v in all circumstances for some time but I fear if some of them should be o or a... --Dine2016 (talk) 03:20, 30 September 2017 (UTC)

@Dine2016: Here's my understanding:

• 同, 俗字, 略字 = v.
• 古字, 篆字 = a.
• 通 needs an actual entry rather than {{zh-see}} a lot of the times.
• 初文, 本字 probably means {{zh-original}} should be used; 本字 is kinda confusing (especially for dialects).
• I'm not quite sure when to use o to be honest.

— justin(r)leung _{{ (t...) | c=› }} 03:32, 30 September 2017 (UTC)

Thanks. Would 云 (yún) be an “simplified and ancient form” (which is not in Module:zh-see) of 雲／云 (yún)? --Dine2016 (talk) 08:15, 19 October 2017 (UTC)

Redirecting to a specific etymology

The documentation mentions using this template under a specific etymology -- but is it possible to redirect to a specific etymology? e.g. if character X etymology N is a variant form of character Y etymology M. This would be a useful feature. Freelance Intellectual (talk) 08:55, 30 April 2019 (UTC)

@Freelance Intellectual: It's not implemented yet. I've brought this issue on Wyang's talk page, but that page got deleted. I think such a feature would be useful for cases like 𬞟, 苹 → 蘋, for copying categories from particular sections (which {{ja-see}} does).

By the way, I think that if the non-lemma is an ancient or obsolete form, it should be judicious in copying categories. For example, 𠄰 → 老 shouldn't copy categories from the modern definitions such as Category:Chinese dialectal terms ("very; quite"), Category:Chinese affectionate terms (老 as in 老王), Category:Mainland China Chinese ("short for 老撾"), etc. --Dine2016 (talk) 09:39, 30 April 2019 (UTC)

copying categories to obsolete or ancient forms

Hi. Should the template copy categories more judiciously when it comes to obsolete or ancient forms?

For example, please take a look at Category:zh:Transgender. 𠈼 clearly shouldn't be there.

(Notifying Kc kennylau, Atitarev, Tooironic, Jamesjiao, Meihouwang, Suzukaze-c, Justinrleung, Hongthay, Mar vin kaiser, Dokurrat, Zcreator alt, Geographyinitiative): --Dine2016 (talk) 03:30, 17 September 2019 (UTC)

I find it jarring. —Suzukaze-c◇◇ 04:25, 17 September 2019 (UTC)

Is there a way to disable variant forms linking to categories? They really shouldn't be in there, since they are not lemmas, just different ways of writing the same word. ---> Tooironic (talk) 10:40, 17 September 2019 (UTC)

Another instance: 墬 should not copy the particle-related categories of 地. --Dine2016 (talk) 04:53, 14 December 2019 (UTC)

@Tooironic: I don't think so. There may be instances where two variant spellings are both in use with competing frequency, and we have chosen one as the lemma arbitrarily. Maybe it's better to distinguish "currently-in-use"/"obsolete" or 全同/非全同? --Dine2016 (talk) 04:57, 14 December 2019 (UTC)

Odd interaction when other templates are used in definition?

On the page 龞, zh-see produces the following message:

For pronunciation and definitions of 龞 – see 鱉 (“soft-shell turtle {{gl|any turtle in the family Trionychidae, especially Pelodiscus sinensis”).

It seems odd that the gloss template is included as text in the definition, and this might be unintended behavior. For reference, the wikitext entry at the page 鱉 is:

[[soft-shell turtle]] {{gl|any turtle in the family [[Trionychidae]], especially {{taxlink|Pelodiscus sinensis|species}}}}

I'm wondering if there is a compatibly issue with gloss (since zh-see failed to produce the parentheses and instead just wrote the template), or if it has to do with there being a taxlink template inside of the gloss template, and this nesting has somehow disrupts zh-see. I'm not very familiar with this, but I don't think it should be the former because a broad compatibility issue would have likely been caught long ago. Either way it appears that zh-see is not producing the text one would expect, but please correct me if I'm wrong. ChromeGames923 (talk) 06:57, 9 October 2020 (UTC)

@ChromeGames923: Yes, this is an issue that I think most Chinese editors are aware of, but haven't really bothered fixing. It does have to do with nesting templates, which this template is really bad at dealing with. — justin(r)leung _{{ (t...) | c=› }} 07:26, 9 October 2020 (UTC)

@Justinrleung I see, thanks for letting me know. In the end it's not particularly problematic but I was just surprised to see how it rendered. Thanks, ChromeGames923 (talk) 22:58, 9 October 2020 (UTC)

@Justinrleung Just noticed the same issue on 上声:

For pronunciation and definitions of 上声 – see 上聲／上声 (“rising tone {{gl|one of the four tones in Middle Chinese, also a tone in various modern varieties, e.g. tone 3 in Standard Mandarin, tone 3 in Meixian Hakka, and tone 2 in Xiamen/Taiwanese Hokkien”).

While the wikitext at 上聲／上声 reads:

# {{lb|zh|Chinese phonetics}} [[rising]] [[tone]] {{gl|one of the four tones in Middle Chinese, also a tone in various modern varieties, e.g. tone 3 ({{IPAchar|/˨˩˦/}}) in Standard Mandarin (marked with a caron [ [[ˇ]] ] in [[Hanyu Pinyin]] and [[bopomofo]]), tone 3 in Meixian Hakka ({{IPAchar|/˧˩/}}), and tone 2 in Xiamen/Taiwanese Hokkien ({{IPAchar|/˥˧/}})}}

zh-see appears to be stripping the lb template as well as parentheses and their contents. Curiously, since the nested templates (IPAchar in this case) are all enclosed in parentheses, it shouldn't even be seeing the nesting. If it were simply a case of zh-see not keeping track of curly brace depth correctly, I would expect the definition line to mangled much worse than it is. 173.71.88.220 22:09, 19 November 2020 (UTC)

Simplified form of variant form

How do I force this template to say "A is the simplified form of B, which is a variant form of C"?

Usually if I leave the second parameter blank this relationship gets automatically detected, but it didn't work on 厘订. If you remove the second parameter (currently I set it to "s") then it will claim that 厘订 is a variant form of 釐訂, which is obviously false from the second character. The template seems to be latching on to the fact that 厘 is a variant of 釐 and ignoring the presence of simplified 订. ChromeGames923 (talk) 06:19, 4 August 2021 (UTC)

@ChromeGames923: It seems to be an issue with the presence of 厘订 in the source code in 釐定. I'm not entirely sure what the best solution is other than the fact that 訂 isn't pronounced the same as 定 in Cantonese, which would mean 釐訂 might need to be a full entry. — justin(r)leung _{{ (t...) | c=› }} 23:16, 4 August 2021 (UTC)

@Justinrleung: I see, since the pronunciation could be different it might not actually be an alternative form, but rather a synonym. I think I understand that distinction better now. That being said, I'm not sure why that would cause this template to misunderstand the relationship between the simplified and traditional forms. I have a feeling that Wiktionary thinks the simplified form of 釐訂 is 釐订, since that it what it will list automatically (in derived terms, alternative forms, etc.) when it comes up. So maybe that makes it think that 厘订 is a variant (of the "simplified" 釐订). ChromeGames923 (talk) 23:35, 4 August 2021 (UTC)

@ChromeGames923: The way {{zh-forms}} detects things is by looking at {{zh-forms}}. Since 釐定 had {{zh-forms|alt=釐訂/厘订|s=釐定}}, 厘订 was detected as being in the parameter |alt=, which would make it a "variant" (because of Module:zh-see#L-115). — justin(r)leung _{{ (t...) | c=› }} 23:44, 4 August 2021 (UTC)

We need to "hard-code" the simplified form because 釐 doesn't always simplify to 厘. — justin(r)leung _{{ (t...) | c=› }} 23:45, 4 August 2021 (UTC)

@Justinrleung: I appreciate the explanation, I think I understand now: because usually the simplified form is not hard-coded so it is technically not in the |alt= parameter, it just displays there when rendered. In that case, might it make sense to modify {{zh-forms}} so that simplified forms (those preceded by a slash) are not detected as variants but rather as being simplified? And indeed, I actually just fixed the simplified forms of 釐 in its derived terms for the reason of it not simplifying all the time. Thanks, ChromeGames923 (talk) 00:12, 5 August 2021 (UTC)

@ChromeGames923: Perhaps it would make sense to change to code to detect it a little more smartly, but I'm not sure if all things after a slash would be simplified. I can think of the case where there could be trad/trad2/simp. — justin(r)leung _{{ (t...) | c=› }} 00:19, 5 August 2021 (UTC)

@Justinrleung: You're right, there could be many different cases that might be hard to account for. Then it might be nice to be able to manually input two-step links into {{zh-see}}, but it's not a major issue. ChromeGames923 (talk) 02:32, 5 August 2021 (UTC)

Hakka Pha̍k-fa-sṳ

Just like how Min Nan has "poj" Pe̍h-ōe-jī code, Hakka should have a "pfs" Pha̍k-fa-sṳ code, for example for khî and sṳ̀
Liggliluff (talk) 11:20, 5 May 2022 (UTC)

@Liggliluff: PFS entries are disallowed by our current consensus, which is at WT:AZH#About_specific_lects. Unlike POJ, PFS does not seem to have much use outside of church publication (and Wikimedia projects). — justin(r)leung _{{ (t...) | c=› }} 14:00, 5 May 2022 (UTC)

Thanks for letting me know, I should refrain from adding those Liggliluff (talk) 18:46, 5 May 2022 (UTC)

Incorrect behavior when target page contains multiple zh-see redirects

When the target page itself contains multiple zh-see templates, targeting it will automatically redirect to the last entry. For example, on the page for simplified 荦峃, this template incorrectly points you to the page 㪐㩿, when in fact the proper behavior would be to just point towards the traditional form 犖嶨, which then links to either 犖确 or 㪐㩿. ChromeGames (talk) 06:25, 7 April 2024 (UTC)