Module talk:Charmap

Adding a feature to show different styles

@GKFX: I am working on project to rebuild the templates that present information on category:Indic letters. I'd like to piggyback off of {{charmap}}, but I have an issue that also presents an opportunity for the development of this template. Basically, with the Brahmi script and other early writing systems, Unicode encodings end up encompassing a superset of all the different eras and styles of an early writing system, and it can become necessary to show example glyphs from multiple styles to truly show a character and its encoding. This also presents an opportunity to extend the idea to modern scripts, where there are very often several quite distinctive writing styles that are legible to readers of a given language - e.g. modern Cyrillic has several letters with distinct cursive forms in different languages, or Fraktur and "Old English" styles of the Latin script are legible to modern German and English readers. What I'd like to do is introduce parameters to elicit a sub-table in the "Preview" cell in charmap that would allow for up to five different styles of each letter to be introduced.

Parameters and how they would be implemented in a cell of the subtable could be:

Parameter	Implementation	Extent
StyleNlabel for N = 1, 2, 3, 4, 5	''{{{StyleNlabel|}}}''	for characters 1-10
StyleN for N = 1-5	<span style="{{{StyleN|}}}">&#xnnnn;</span>	for characters 1-10
StyleX-Nlabel for X = 1-10 and N = 1-5	Same as StyleNlabel	for character X only
StyleX-N for X = 1-10 and N = 1-5	Same as StyleN	for character X only
ImageX-N for X = 1-10 and N = 1-5	[[File:{{{ImageX-N}}}]]	for character X, style N

Example

A hardcoded example, showing just the top few rows. When embedding tables, the inside table has to use the <table>...</table>, <tr>...</tr>, and <td>...</td> tags directly, instead of the standard wikimarkup for tables, so if you look at the wikicode, you can see how that's done.

Character information

Preview	Ashoka Gujarat Gupta		Ashoka Kushan Gupta 𑀓
Unicode name	brahmi letter gha		brahmi letter ka
Encodings	decimal	hex	decimal	hex
Unicode	69654	U+11016	69651	U+11013

{{charmap
| 11016
| 11013
| name1 = Brahmi letter Gha
| name2 = Brahmi letter Ka
| Style1label = Ashoka
| Style1-2label = Gujarat
| Style2label = Kushan
| Style3label = Gupta
| Style1 = font-family:Noto Sans Brahmi; font-style:italic; font-size:24pt;
| Image1-1 = [[File:Brah gh.svg]20px]
| Image1-2 = [[File:Gupta gujarat gh.svg]20px]
| Image1-3 = [[File:Gupta allahabad gh.svg]20px]
| Image2-2 = [[File:Gupta ashoka k.svg]20px]
| Image2-3 = [[File:Gupta allahabad k.svg]20px]
}}

Unfortunately, I am a template programmer, but I don't know lua at all. I've looked over the code for this module, but can't see how to implement something like this, so I will need help from you or somebody who knows how to program modules to get this off the ground. Much thanks for any help, VanIsaac, MPLL ^cont_WpWS 06:43, 1 October 2021 (UTC)

@Vanisaac OK, I have been on a bit of a Wikipedia break but I will try to make time for this this weekend or sooner. (It’s worth pointing out that, in general, you don’t have to specify hard limits for numbers in parameter names in Lua modules, as you can just loop over as many parameters as get provided.)@Vanisaac User:GKFX^talk 07:15, 1 October 2021 (UTC)

Oh, nice to know about the lack of limits on numbered parameters. As you can tell, I am very keyed in to template syntax limitations and logistics. And no worries about the timeline on this. There is an acceptable median state while I am trying to transition everything over to the new implementation of this information, and I just kind of realized a couple days ago that my old friend {{charmap}} was probably a really good solution, but it will probably be another month or so before I fully roll out the whole new setup. I had steeled myself for a hefty bunch of template programming when I come to find out the old cludge I made eight years ago had gotten a nice new makeover as a module. VanIsaac, MPLL ^cont_WpWS 08:05, 1 October 2021 (UTC)

With the testcases I've set up, I'm noticing some mechanisms that are looking nice, but also an issue with prioritization that I would hope to get changed. If I'm reading the code correctly, it looks like you are conditioning the stylized output on the presence of a matching style label, which seems like a really user-friendly control mechanism to me. I may have further feedback as I try different testcases, but it's looking good for now. However, when it comes to choosing what gets displayed, I feel like some adjustment should happen to ensure the specific overrides the general. So ImageX-N, where the user has specified a particular image for a character in a style, should be the first choice for being displayed. Next would be the character with styling specified for that character with StyleX-N. Ideally the character stylized with StyleN would be next, followed by ImageX, with unstyled plain text as the last resort. But if it's easier to program, it's probably fine for StyleN to be lumped in with the plain text as the last option. I hope this doesn't throw too much of a monkey wrench into the module logic structure, but let me know if there are good reasons why it is better to go with something else. It's actually looking really good, and thank you for all of your hard work! VanIsaac, MPLL ^cont_WpWS 21:21, 1 October 2021 (UTC)