Template talk:Ding

Nonstandard mappings

I strongly disagree with using nonstandard mappings outside of the Private Use Area (PUA) in page text. For various reasons (the find function, copy pasting text, screenreaders, readability of wikitext), we should ensure any character we're using to represent game text is semantically equivalent to the Unicode character, not merely corresponding to the same codepoint. Otherwise, we're effectively using a symbol font with a non-UTF-8 encoding on a UTF-8 website.

There is no reason anyone would reasonably expect {{ding|①}} to render as ① (fullwidth neutral face). If we're going to use a codepoint to represent those kinds of symbols, it should either be a PUA codepoint (like U+E081, as we currently do in Gen 5 contexts with {{ding|}}) or a semantically equivalent emoji (U+1F610 😐). I realize that we're just reusing the font used by the PGL; I don't have a problem with having a font on the site that supports those non-standard mappings, as long as we never use those mappings. (I think rendering $ as the Poké Dollar sign is fine, as the two are semantically similar enough.)

Even with PUA codepoints, it's still probably a bad idea to ever explicitly use PUA codepoints on the wiki (although they're certainly preferable to non-standard mappings of defined non-PUA Unicode characters). For the faces and arrows, we should be using semantically equivalent Unicode codepoints (e.g. 😐, ⤴, 💤) even if they don't match the real PGL font. For stuff like halfwidth characters that have fullwidth Unicode counterparts, my strong preference would be to still have the actual codepoint used be the Unicode character, but just use a separate halfwidth font. So instead of needing to use {{ding|}} to render a halfwidth cloud, it would be placed using something like {{ding-hw|☁}} and use the codepoint for ☁ (U+2601) instead of a PUA one. --SnorlaxMonster 14:20, 2 March 2024 (UTC)

The guidance currently on the template page is primarily based on Wikipedia's manual of style regarding PUA characters and specifying fonts for them. All of the locations where this template is currently used are places where the characters themselves are being discussed, and PGLDings—the font from the PGL this template uses—is by design a dingbat font for these symbol characters.

I can get behind not using the non-standard mappings and using just the PUA codepoints, since that's the most recent Unicode encoding for these characters. The official Unicode mappings we have for  are, in summary:

• PBR/Ranch: ㌀㌁㌂㌃㌄㌅㌆ in CJK Compatibility
• BW/B2W2: ①②③④⑤⑥⑦ in Enclosed Alphanumerics
• XY/ORAS/SM/USUM/PGL: U+E081..U+E087 in the Private Use Area

Because we specify that this particular font should be used, host said font on our servers, and use this template to mark their usage, I would still prefer to use private use characters for them, since they've always been treated that way in the games/on the PGL even when Unicode was otherwise being used. Pokémon.com still uses a icon font for their header icons with PUA mappings, so I don't think it's unreasonable to be using PUA codepoints for these symbols (especially with the issues the site still has with code points above U+10000 anyway).

As for the halfwidth characters, they should almost always just be written using the Unicode characters anyway. For instance, in most contexts we wouldn't be writing Nidoran♀'s name in the DS/3DS games as Nidoran just because it's technically a different character from ニドラン♀, but having the font still leaves the option open for writing about said difference in a technical context where it matters. --Abcboy (talk) 19:58, 29 March 2024 (UTC)

It's true that this template is currently being used in an extremely limited number of places, where the characters themselves are the relevant subject. I think the current template documentation isn't sufficiently narrow about when this template should be used, however. I think the only cases we would ever use this template for are U+E081-E087 (and maybe their halfwidth variants, but likely not), and the template documentation should specify that. There is currently a disclaimer that it shouldn't be used for certain cases, but both of the example cases it lists to avoid using are instances which are not listed in the "Examples" table, implying that all instances in the "Examples" table are valid use cases; either we should be listing all non-standard mappings even if we don't want people to use them, or we should only be listing the mappings that there are legitimate uses for. The "Examples" table currently seems to be attempting to document encoding differences between the DS and 3DS games, rather than functioning as an explanation of how to use the template.

For the cases where we do want to distinguish the halfwidth forms from the fullwidth forms, I still think it would be better for the input to be the standard codepoint and the output be the character displayed as halfwidth (but still use the codepoint of the original character). So you could specify {{ding-hw|♀}} as the input and get  displayed as the output. The best way I can think of to do that would just have a different halfwidth font, although maybe there's some way to use the CSS property text-transform to achieve this (but as far as I can tell, it's only useful for converting halfwidth to fullwidth, not the other way around).

I will note that the Wikipedia page MOS:PUA includes the following line: "However, whenever a PUA character has a Unicode equivalent, it should instead be replaced with that equivalent (Unicodified)." If we are basing our policy on theirs, avoiding PUA characters where possible should be part of it. And IMO, I think all of the PUA characters have fairly obvious Unicode counterparts we can use (except maybe the Pokémon Dollar sign, but that's already being mapped to the dollar sign). --SnorlaxMonster 02:35, 30 March 2024 (UTC)