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)

Yes, it's all conditional on the StyleNlabel or StyleX-Nlabel. I personally think that the two CSS attributes should always apply if provided, as it can always be helpful to be able to just add some CSS, even potentially to an image, and there are enough parameters provided to control every character individually. On the subject of images, the priority order is currently ImageX-N, ImageX, styled character. I'm wondering if there is any point in allowing ImageX to ever appear when splitting into multiple styles, as it makes far more sense to use ImageX-N to actually put the image in the right place. User:GKFX^talk 13:44, 2 October 2021 (UTC)

I think there are possible usage cases for ImageX to appear several times, with a few exceptions, but it might best to pop up an error message if you have both ImageX and ImageX-N with the same X due to the likelihood that there's something amiss. In terms of the behavior, right now my testcase has |Image2-3=[[File:Greek lc theta var.svg|15px]] and |image2=[[File:Greek lc theta.png|10px]], but File:Greek lc theta.png shows up in all three styles, so that's what I was hoping to get fixed. VanIsaac, MPLL ^cont_WpWS 07:38, 3 October 2021 (UTC)