Talk:ᵈ

RFV discussion: February–March 2022
Translingual. Rfv-sense: Another pre-stopped consonant. Chuck Entz (talk) 04:25, 25 February 2022 (UTC)
 * 1) a superscript d


 * Unicode note that U+1D48 is intended for use as superscript here. Theknightwho (talk) 05:05, 25 February 2022 (UTC)
 * All I see is &lt;super> followed by the code for another character. What data in a data file means is dependent on the file structure. What does being in that field mean? Show me the file structure. Saying that this is a superscript form of "d" is not the same as saying that it's intended for use as a superscript. As for what letters in that block are, see page 296 of this pdf, where it says:

Most of the characters in the first of the two adjacent blocks comprising the phonetic extensions are used in the Uralic Phonetic Alphabet (UPA; also called Finno-Ugric Transcription, FUT), a highly specialized system that has been used by Uralicists globally for more than 100 years.
 * Or better yet: Modifier letter. The purpose of these characters is to modify the phonetic value of a neighboring phonetic symbol/letter in a phonetic transcription. They coincidentally have the form of superscripts, but they aren't intended to be used as superscripts except in an extremely specific context.


 * I'm not saying they can't be used to represent superscripts in documents where you're only interested in the appearance, but they aren't the same thing. An entry with a Roman C in a Russian word instead of Cyrillic С may be visually identical to the all-Cyrillic spelling, but it's completely wrong for an online dictionary. Whenever we find something like that, we either move it to the correct spelling or delete it on the spot- no RFD necessary. Chuck Entz (talk) 06:23, 25 February 2022 (UTC)
 * Note Table 14 in section 5.7.3 of Unicode's Character Database here:"Superscript form"This refers to decomposition mapping, which (in simple terms) is referring to where one or more characters are equivalent to another one, perhaps with some kind of modification.
 * Where you say "All I see is followed by the code for another character", you can quite easily check that that other character is, in each case, the ordinary Latin character in question that it is a superscript version of: ( ᵈ ) is the equivalent to, and U+0064 is d.  ( ᵗ ) is the equivalent to  , and U+0074 is t. Compare this to, say,   Â, which has  (A + ◌̂) in the same field. The fact that these were added due to their use in IPA does not change the fact that they are recognised as being superscript forms. It's even repeated on the character chart for this Unicode block here. The reason that equivalents haven't been added to the superscript block is because letters were only added to that block in order to fill the gaps: it only contains ⁱ and ⁿ. There is no alternative option, here.
 * Even aside from that, trying to draw a semantic difference is as unhelpful as saying that we can't recognise different uses of characters like # or / because they're intended for some other use. Fundamentally, it's prescriptivist, but even on your own terms the evidence is right there.
 * Theknightwho (talk) 16:11, 25 February 2022 (UTC)
 * After reading up on this, I see you have a point. Both rfvs- withdrawn. Chuck Entz (talk) 22:09, 25 February 2022 (UTC)
 * Many thanks. For what it's worth, these characters are picked up correctly by text search - this equivalence issue is something that has also come up on Wikisource, where certain equivalences get implemented (e.g. s and ſ) and others do not (e.g. ligatures like ﬃ or ﬆ), which creates usability issues. Theknightwho (talk) 23:00, 25 February 2022 (UTC)


 * These dedicated-codepoint superscript characters do not appear to be functionally equivalent to the ASCII equivalents when searching within a page.
 * Over at 2ⁿᵈ, for instance, if I press CTRL+F in my browser and search for  (lower-case ASCII "N"), I see no hits upon the "n" in the headword.  Likewise if I try searching for "d" (lower-case ASCII "D").
 * If I try searching this page for "t" (lower-case ASCII "T"), I cannot find any hits for the superscript-"t" in the heading of the preceding thread at Requests_for_verification/Non-English. If I try searching this page for "d" (lower-case ASCII "D"), I do find the "d" in the heading for this thread.  Although this appears in the wikitext as dedicated-codepoint superscript character ᵈ, an inspection of the rendered source in the browser shows that this is replaced somewhere (by the MediaWiki server? by the browser?) with   (lower-case ASCII "D" with superscript tags).
 * I also see that font support for the dedicated-codepoint superscript characters is inconsistent: the "n" and "d" at 2ⁿᵈ appear in markedly different sizes, and the "i" in maᵗⁱᵉ has a thinner line weight and a higher baseline than either the "t" or "e".
 * These dedicated-codepoint superscript characters entail various usability problems. I do not think we should use them widely without further examination of the issues and, ideally, better browser and font support.  ‑‑ Eiríkr Útlendi │Tala við mig 00:27, 24 March 2022 (UTC)
 * That appears to be an issue with your browser with most of those, as I'm unable to replicate these issues in Chrome, and unless you want to start removing all entries for which you don't have proper font support, I don't think that there is likely to be a consistent solution here. Fundamentally, we should go by what the Unicode standard says, and not the idiosyncrasies of outdated browsers.


 * The only one that isn't is the issue of the glyphs being different sizes due to MediaWiki not handling certain codepoints properly, and it is something that should be relatively straightforward to solve. In the meantime, it is not a huge issue, and is ultimately because of the underlying font having a problem. By rights, it shouldn't really matter whether the HTML is one or the other, as the font should be handling both the same. Theknightwho (talk) 08:10, 24 March 2022 (UTC)
 * We shouldn't be privileging a single browser. If something isn't reasonably well supported by the top three or six browsers on desktop OSes (Win, Mac, Linux) and on smartphone OSes, we should not be depending on it for core functions or principal-namespace display. DCDuring (talk) 15:14, 24 March 2022 (UTC)
 * It's complying with the Unicode standard, not privileging a single browser. There are quite a few scripts that have considerably worse support, and we aren't talking about moving pages using those to nonstandard page names either.
 * It's a bit frustrating that the argument has now been entirely flipped from saying that these weren't compatible with the Unicode standard, to now saying that the Unicode standard isn't important when deciding on the page name. There's a serious inconsistency in approaches there, and even though the arguments have been put forward by different people, it suggests a lack of consensus as to what the policy should be.
 * This is made worse by the fact that the logical conclusion of this argument is that we would also need to move the IPA definition for ᵈ to d as well, which is completely absurd. Theknightwho (talk) 15:49, 24 March 2022 (UTC)