Template talk:Infobox grapheme

(Redirected from Template talk:Infobox grapheme/testcases)
Latest comment: 10 months ago by FeRDNYC in topic This disaster infobox
WikiProject iconWriting systems Template‑class
WikiProject iconThis template falls within the scope of WikiProject Writing systems, a WikiProject interested in improving the encyclopaedic coverage and content of articles relating to writing systems on Wikipedia. If you would like to help out, you are welcome to drop by the project page and/or leave a query at the project’s talk page.
TemplateThis template does not require a rating on Wikipedia's content assessment scale.
WikiProject iconTypography Template‑class
WikiProject iconThis template is within the scope of WikiProject Typography, a collaborative effort to improve the coverage of articles related to Typography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
TemplateThis template does not require a rating on Wikipedia's content assessment scale.

A talk page for Template:Infobox grapheme, a template for representing information about a letter/character.

Needs full rework edit

This is one of the most ill-designed, most cluttered and most dysfunctional infobox templates I've ever encountered. I'm hardly surprised to find that the person who created it turned out to be a ban-evading sock. Back when this was new I once challenged its design at Wikipedia talk:WikiProject Writing systems/Archive 10#New "Infobox grapheme"?, but unfortunately no action was taken as a result. I'm now planning to cut the template down to reduce the clutter. Current drafts at Template:Infobox grapheme/testcases and Template:Infobox grapheme/sandbox. Fut.Perf. 08:04, 19 April 2020 (UTC)Reply

intrusive background to "This article contains IPA phonetic symbols." edit

The purple background to the section "This article contains IPA phonetic symbols." is visually intrusive and contrary to MOS:ACCESS (for contrast reasons). Please change to a simple light grey. --John Maynard Friedman (talk) 16:42, 8 March 2021 (UTC)Reply

This disaster infobox edit

Future_Perfect_at_Sunrise levels some good criticisms of this template, above, but unfortunately any effort to improve it seems to have stalled, and anyway even in the sandbox version I'm not sure the biggest issues have really been addressed.

I'm NOT a subject-matter expert, but to provide a layperson's perspective (something that, it seems, is sorely needed here), the infobox just seems overwhelmed by questionably-useful cascades of apparently-related glyphs, presented absent any useful context and rendered (due to the default 88% font size for Infobox text) too small to really appreciate (or even make out, in some cases). But honestly, I feel the bigger problems are with not the template itself, but the input being provided to it on the various articles where it's used. Guidance, more than design effort, may be what's really needed.

I get why the "Ancestors" hierarchy is presented as a nested bulleted list, and presumably it's at least possible for certain graphemes to have a more complex ancestry than the simple linearly-increasing indentation found on articles like A or J.

But why are the "Descendants" and "Sisters" presented vertically (descendants with bullets, sisters without), when all it does is waste a ton of space and stretch the infobox far down length of the article? Why are the "Phonetic usage" items presented symbolically (and, again, wastefully-vertically), when the articles those symbols link to have actual, descriptive titles that are, most likely, far more meaningful to the average Wikipedia reader?

Surely at least "Sisters", and probably "Descendants" as well, can make use of {{hlist}} to present their respective series of glyphs in a more compact manner? Aesthetically, it feels like an easy fix, to trade one of these for the other:

Possible configurations of A infobox data
Current Compact
A
A a
(See below)
Usage
TypeAlphabetic and Logographic
History
Development
Time period~-700 to present
Descendants • Æ
 • Ä
 • Â
 •
 • Λ
 •
 • ª
 • Å
 •
 • @
 •
 •
 •
 • 🅰
Sisters𐌰
А
Я
Ә
Ӑ
א
ا
ܐ


𐎀


ء
Ա ա


Variations(See below)
Other
This page contains phonetic transcriptions in the International Phonetic Alphabet (IPA). For an introductory guide on IPA symbols, see Help:IPA. For the distinction between [ ], / / and  , see IPA § Brackets and transcription delimiters.
A
A a
(See below)
Usage
TypeAlphabetic and Logographic
History
Development
Time period~-700 to present
Descendants
Sisters
Variations(See below)
Other
This page contains phonetic transcriptions in the International Phonetic Alphabet (IPA). For an introductory guide on IPA symbols, see Help:IPA. For the distinction between [ ], / / and  , see IPA § Brackets and transcription delimiters.
A
A a
Usage
TypeAlphabetic and Logographic
Phonetic usage[a] Open front unrounded vowel
[ɑ] Open back unrounded vowel
[ɒ] Open back rounded vowel
(etc...)
History
Development
f1
  • A a
Other
This page contains phonetic transcriptions in the International Phonetic Alphabet (IPA). For an introductory guide on IPA symbols, see Help:IPA. For the distinction between [ ], / / and  , see IPA § Brackets and transcription delimiters.

(Combining the three representations of Aleph — presented on three separate lines in the original format — into a single, space-separated hlist bullet item also helps make it clearer that, just like Ա and ա, they all link to the same article.)

Regarding the phonemes. (And I now see that the IPA notice at the bottom isn't conditional on there being arguments to the |phonemes= parameter, when it obviously should be. ...But that's a relatively simple fix.) With the phonemes, as I was saying above I suspect it might be more helpful to readers if we're less conservative in how we present those links, and instead include the actual title of the article that's represented by the symbol (in addition to the symbol). That may require the templates that create those links to support, and output, an "expanded form" for cases (like these) where the symbol isn't being used to represent itself, but rather is actually meant to represent the article about itself. i.e... →

That could be achieved with a simple adjustment to Module:IPA symbol and the {{IPAlink}} family of templates that call it — say, perhaps, a new |title= parameter, so that {{IPAblink|a|title=true}} transforms "[a]" into "[a] Open front unrounded vowel". FeRDNYC (talk) 18:31, 30 April 2023 (UTC)Reply

But why are the "Descendants" and "Sisters" presented vertically (descendants with bullets, sisters without), when all it does is waste a ton of space and stretch the infobox far down length of the article?

Actually, I see now that the "real" A presents those items in a nicely-formatted {{grid list}}s, which solve that issue. But not all of the letter articles follow suit (J looks much like the A samples here), so I guess what's really needed is for editors to go update the rest of those articles to emulate A.

I get why the "Ancestors" hierarchy is presented as a nested bulleted list, and presumably it's at least possible for certain graphemes to have a more complex ancestry than the simple linearly-increasing indentation found on articles like A or J.

Actually, I guess it's not possible, because the way the |famN= cascade is implemented, the hierarchy is fixed to only descend linearly. So, now we're back to that being of questionable usefulness.
Those issues aside, I've created a new version of the template in the sandbox. (Overwriting the prior work Future_Perfect_at_Sunrise did, with regret — but it's still in the history!) My version fixes some of the actually-technical issues I found with the template:
  • Display of the {{IPA notice}} is now conditional on there being arguments to the |phonemes= parameter
  • The cascade logic for the |famN= parameters is now markedly simpler and more intelligent. The original implementation had it so close to correct, but whoever wrote it failed to realize that if both the opening and (in reverse) closing of each level of the list hierarchy were made conditional on each parameter level being present, then the final, central self-reference only had to be written once, and it would always end up at the correct level. So, now, that's how it works.
  • I fixed the spelling of directon to be direction, so that parameter can actually work now. (Or, will if the sandbox is taken live.)
  • Like Future_Perfect_at_Sunrise, I removed the brute-force categorization (though it was already in a noinclude, and therefore pretty pointless anyway). While I considered adding a {{main other}} wrapper and bringing it back to mainspace, as the docs for that very template note that isn't supported by the guidelines. Best to just skip it.
I'll write some additional test cases for the aspects I changed, and change the sample content to match A in its use of {{grid list}}. Hopefully then, more editors will be inspired to spread that feature to the real mainspace articles that could sorely use it. FeRDNYC (talk) 20:10, 30 April 2023 (UTC)Reply
Thank you very much for taking up the initiative of improving this box. I'm afraid I lacked the energy to go through with it last time. But yes, please do go ahead with any restructuring you see fit; this already looks a lot better. Fut.Perf. 08:43, 1 May 2023 (UTC)Reply
OK, I've had some more time to spend on this:
  1. I completely refreshed the test cases formatting and content. They now use {{Testcase table}} to show the two infobox versions side-by-side, they're |_collapsible=y so they'll fold up automatically when the sandbox output matches the live rendering, and the actual code passed to the test transclusions now borrows "best-practices" code from the live A article at the time of this writing, so that the test is more representative of what the infobox should look like in the wild.
  2. In the sandbox, I added |autoheaders=y to the {{Infobox}} transclusion, so now headings that don't contain any rows will be suppressed completely. An example can be seen in the second testcase.
  3. I also changed how the Development infobox item renders, so that unless at least |fam1= is set in the transclusion, Development will be completely suppressed, instead of just uselessly repeating the infobox title. Again, the second test case demonstrates the effects.
I think the sandbox is pretty much ready to go live, now, but I'll hold off a bit in case anyone objects / notices any issue I missed. FeRDNYC (talk) 22:22, 3 June 2023 (UTC)Reply