Template talk:Infobox Unicode block

Early Dynastic Cuneiform
Early Dynastic Cuneiform
Related Unicode blocks
	Cuneiform; Cuneiform Numbers and Punctuation;

Suggestions

Hi Vanisaac. I suggest the next changes.

Do not use background colors. Such "information" is confusing, and nowhere explained. WP:COLOR explains why information-by-color-only is not a good idea. On top of that, coloring based on a version is quite irrelevant, version is just history.
Eh, probably right. I'll zonk it out. Done Van Isaac_{WS Vex}^contribs

Hmm, WP:COLOR only seems to indicate that information should not solely be indicated with color. If the information is available elsewhere, it doesn't really have much to say. It's irrelevant, because I think that a consistent light blue color is probably best anyway. Van Isaac_{WS Vex}^contribs 01:17, 23 March 2013 (UTC)[reply]

Move the detailed version numbers to the very bottom (right above the note). This is detailed andhistorical information. The overview numbers then show nicely below the range-information. Maybe add a divider line above "range" to make is a group? -DePiep (talk) 12:06, 22 March 2013 (UTC)[reply]
Should be easy enought to renumber. Done Any other suggestions or thoughts? Van Isaac_{WS Vex}^contribs 00:10, 23 March 2013 (UTC)[reply]

Usage what?

Must say, the top 'Usage' section does not mean anything to me. -DePiep (talk) 22:23, 28 March 2013 (UTC)[reply]

Is that a little clearer? Van Isaac_{WS Vex}^contribs 00:24, 29 March 2013 (UTC)[reply]

Unexpected redlink

For example, page CJK Radicals Supplement. Why does this template, on that page, produce a red link while pure pagename=block name? -DePiep (talk) 22:32, 28 March 2013 (UTC)[reply]

I don't know what you're talking about. Van Isaac_{WS Vex}^contribs 00:24, 29 March 2013 (UTC)[reply]

The page has {{Infobox Unicode block}}, all fine. Then, the template box shows title CJK Radicals Supplement in a red link. -DePiep (talk) 00:50, 29 March 2013 (UTC)[reply]

The infobox shows up just fine for me. Van Isaac_{WS Vex}^contribs 01:06, 29 March 2013 (UTC)[reply]

See page CJK Radicals Supplement. It has {{Infobox Unicode block}}. Top right of that page, the {{Infobox Unicode block}} title, gives a red wikilink. -DePiep (talk) 01:14, 29 March 2013 (UTC)[reply]

There are literally zero red wikilinks on that page. There is something wrong with your browser/connection. Van Isaac_{WS Vex}^contribs 05:13, 29 March 2013 (UTC)[reply]

You are right. It is even worse. It uses the darkred color, against WP:COLOR.

This is a (secundary) reason to revert using font-color in the caption. See below: #Caption font color -DePiep (talk) 22:55, 30 April 2013 (UTC)[reply]

Caption font color

I have undone the coloring of the caption font color. First of all, Unicoded does not have a "script type", so we are entering OR. Secondary, it uses color without meaning. The reader can not see the meaning (it is not even elsewhere, as in a key/legend). Third, one color was red, which suggested a redlink. -DePiep (talk) 22:55, 30 April 2013 (UTC)[reply]

Please keep disambiguation

For the script1 parameter, many pages that use this template have a comment of "Please keep disambiguation so template works" followed by an internal link (for example, [[Glagolitic (script)|Glagolitic]]) on the Glagolitic (Unicode block) article. I don't see where the template is doing anything special with this. Is it just a link with a label? If so, can we dispense with this confusing (at least to me) warning? DRMcCreedy (talk) 02:44, 29 August 2014 (UTC)[reply]

You're right. -DePiep (talk) 15:15, 29 August 2014 (UTC)[reply]

Grouping data

I note that the infobox has two sorts of data: about block content (scripts, symbols) and block structure (U+ numbers, plane, non-assigned code points). I propose to put those together. This being a block, the content (script) data can go below. Maybe add header "Content"? -DePiep (talk) 17:52, 20 November 2016 (UTC)[reply]

Version details can stay at the bottom, with a header. -DePiep (talk) 17:54, 20 November 2016 (UTC)[reply]

Links to previous and next blocks

I often wish there were links to the previous or next blocks, as in the Wiktionary appendices on Unicode blocks, such as wikt:Appendix:Unicode/Latin-1 Supplement. This can be done with Lua. Would it be appropriate in this infobox? — Eru·tuon 21:23, 15 April 2018 (UTC)[reply]

Same here but couldn't decide on formatting and if it should be next by code point range, next by block name, or both. DRMcCreedy (talk) 21:26, 15 April 2018 (UTC)[reply]

Well, personally I've only been interested in neighboring blocks by codepoint. I don't know why one would want to find the next or previous block by alphabetic order, because that is often meaningless: for instance, Basic Latin borders Bamum Supplement and Bassa Vah. What would be more useful is links to other blocks that contain characters in the same script: Basic Latin, Latin-1 Supplement, Latin Extended-A, Latin Extended-B, Latin Extended Additional, Latin Extended-C, Latin Extended-D, Latin Extended-E. — Eru·tuon 00:44, 16 April 2018 (UTC)[reply]

Related blocks

In Early Dynastic Cuneiform (Unicode block), Theknightwho added this hatnote:

While being GF, and a good idea, I have removed it [1] with es

"rm 'see also' hatnote (goodfaith): obviously content related, so should be in article body (infobox? See also section?)".

Now I am here to propose such addition to article content.

Proposal 1: in Infobox subsection, for content-related Unicode blocks, add |related blocks= to list these. For example:

It will require discipline, from this intention, to limit the to content-related (ie, limit to same script, or same symbol set).

-DePiep (talk) 09:40, 27 February 2022 (UTC)[reply]

I support this proposal. DRMcCreedy (talk) 17:21, 27 February 2022 (UTC)[reply]

I have re-added the hatnote by Theknightwho (OP): many Block articles have it this way, so better consistent. -DePiep (talk) 17:31, 27 February 2022 (UTC)[reply]

Script in PUA

Cirth § ConScript Unicode Registry is a script published being in PUA (private use block). We could think of a better presentation of this notion. -DePiep (talk) 11:02, 27 February 2022 (UTC)[reply]

Created Category:Miscellaneous Unicode blocks (8) for these. ConScript_Unicode_Registry lists many more. Maybe thoser PUA subs are unfit for {{Infobox Unicode block}}. -DePiep (talk) 13:06, 27 February 2022 (UTC)[reply]

The category also contains deleted blocks (version 1–>2 etc.), like Hangul (obsolete Unicode block). (Could not find, easily, list of changes at Unicode-sites, e.i. definitive formnal block changes back then). HTH -DePiep (talk) 07:42, 28 February 2022 (UTC)[reply]

Parameter "latest change"

I have boldly added |latest change= to the live infobox. Per suggestion by Spitzak on my talkpage.

Usage: it requires a version number: |latest change=14.0 → [see example in the documentation]. Later we can expand this with more options (like free text, reference).

I hereby ask Drmccreedy: when you edit any Block for version 15, please add |latest change=15.0. It will show, and we can find it back later on. DePiep (talk) 15:57, 13 September 2022 (UTC)[reply]

I can use it although it seems that it should be a calculated value based the other parms. And should probably be latestchanged (without a space). DRMcCreedy (talk) 19:09, 13 September 2022 (UTC)[reply]

There are changes to a block that cannot be calculated: I just met three in v15: new abbreviations &tc., U+0019, U+0616, U+1BBD. Anyway, worth to keep the idea & develop then. I myself see the need for freetext additions. Since there is no error, we can postpone this development. DePiep (talk) 19:27, 13 September 2022 (UTC)[reply]

Replacing the `codechart` parameter

I'm proposing a change in how this template shows links to the Unicode PDF code chart and the webpage/namelist.
Some background:

On 2022-02-25 user @Theknightwho: added the codechart parameter to show a link to Unicode's PDF code chart.
On 2023-06-11 @Hnvnc: added the ability to autogenerate the PDF and webpage/nameslist links based on starting code point if codechart is absent. Great feature.
In July 2023 I removed the codechart parameters on all the articles where it was just the starting code point, letting the template autogenerate the links. That only leaves these articles to consider:
- Cirth#ConScript Unicode Registry doesn't use the codechart parm so both the PDF and webpage/nameslist links are bad (Error 404)
- Hangul (obsolete_Unicode_block) has three infoboxes:
  - Korean Hangul Syllables Infobox uses codechart = https://www.unicode.org/versions/Unicode1.0.0/CodeCharts1.pdf#page=33 which is fine for the PDF link but the webpage/namelist link is wrong and goes to CJK Unified Ideographs Extension A because of the reused starting code point
  - Hangul Supplementary-A doesn't use the codechart parm and both autogenerated links are bad (Error 404).
  - Hangul Supplementary-B has the same issue as -A
- Private Use Areas doesn't use the codechart parm on any of its three infoboxes:
  - Private Use Area infobox is fine as-is
  - Supplementary Private Use Area-A infobox has an OK PDF link but a bad webpage/nameslist link (Error 404)
  - Supplementary Private Use Area-B has the same issue as -A
- Tengwar#Unicode doesn't use the codechart parm so both the PDF and webpage/nameslist links are bad (they point to the Private Use Area because the first code point for this ConScript block is U+E000)
- Tibetan (Unicode block) has two infoboxes:
  - Tibetan doesn't use the codechart parm and both autogenerated links are correct.
  - Tibetan (Unicode_block)#Former Tibetan block uses codechart = https://www.unicode.org/versions/Unicode1.0.0/CodeCharts2.pdf#page=100 so the PDF link is correct but the webpage/nameslist link goes to the Myanmar namelist because of the reused starting code point

My proposal is to delete the codechart parm and add the codechartoverride parameter:

If codechartoverride=omit is specified, omit both links.
If codechartoverride=https://... is specified, use the supplied URL for the PDF link and skip the webpage/namelist link.
If codechartoverride isn't specified, autogenerate both links as is currently done.

After the template is changed:

Add codechartoverride=omit to Cirth#ConScript Unicode Registry, Hangul Supplementary-A, Hangul Supplementary-B, Tengwar#Unicode, and Tibetan (Unicode_block)#Former Tibetan_block
Update Supplementary Private Use Area-A infobox with codechartoverride=https://unicode.org/charts/PDF/UF0000.pdf so no webpage/nameslist link is produced
Update Supplementary Private Use Area-B infobox with codechartoverride=https://unicode.org/charts/PDF/U100000.pdf so no webpage/nameslist link is produced

I think this addresses all the issues in how code charts/namelists are linked. Does anyone have any issues with this approach? DRMcCreedy (talk) 17:44, 30 July 2023 (UTC)[reply]

Thank you very much @Drmccreedy for catching the edge cases. My apologies for not considering potential issues, as I initially only aimed to get the link to the webpage into the infobox. Hnvnc (talk) 18:23, 30 July 2023 (UTC)[reply]

I don't think we even need a new codechartoverride parameter, just retool the existing codechart parameter to handle codechart=omit, and you should be good to go. Van Isaac, GHTV^cont_WpWS 23:01, 30 July 2023 (UTC)[reply]

We would also need to change the behavior so if codechart is used, no link to the webpage/namelist is created. Initially, codechart was the only way to get the PDF link displayed then autogeneration was introduced. That's why I'm recommending changing the parameter name to codechartoverride to make it clear that it overrides the automatic generation of the PDF and webpage/namelist links. DRMcCreedy (talk) 23:41, 30 July 2023 (UTC)[reply]

The problem is that you're going to have to go through and change all the extant instances of codechart into codechartoverride, when all except the few "omit" instances are going to be absolutely identical in parameter value. And when looking at the functionality being implemented, codechart=omit is actually a better description of the behavior than codechartoverride=omit, while codechart=http://example.com is just as descriptive as codechartoverride=http://example.com. The only time an editor who would even notice a change in functionality is if they used the "omit" keyword. Changing the parameter name can only have a negative effect when editors who are used to the extant parameters don't get their desired results after the change. Van Isaac, GHTV^cont_WpWS 00:58, 31 July 2023 (UTC)[reply]

OK. If the hangup is changing the parameter name, here is my revised proposal:

If codechart=omit is specified, omit both links.
If codechart=https://... is specified, use the supplied URL for the PDF link and skip the webpage/namelist link. This change affects the three instances where the codechart parameter is currently used.
If codechart isn't specified, autogenerate both links as is currently done. This is the 325 times the "Infobox Unicode block" template is currently included without the codechart parameter.
Any objections? DRMcCreedy (talk) 03:02, 31 July 2023 (UTC)[reply]

I've made the change to the codechart parm as outlined. DRMcCreedy (talk) 02:48, 4 August 2023 (UTC)[reply]

@Drmccreedy Thank you. Great solution. Hnvnc (talk) 04:43, 4 August 2023 (UTC)[reply]