Template talk:Infobox Unicode block

Suggestions

edit

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 VanIsaacWS Vexcontribs
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. VanIsaacWS Vexcontribs 01:17, 23 March 2013 (UTC)Reply

Usage what?

edit

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? VanIsaacWS Vexcontribs 00:24, 29 March 2013 (UTC)Reply
edit

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. VanIsaacWS Vexcontribs 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. VanIsaacWS Vexcontribs 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. VanIsaacWS Vexcontribs 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

edit

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

edit

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

edit

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

edit

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
edit

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:
Early Dynastic Cuneiform
Related Unicode blocks

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

edit

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"

edit

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

edit

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

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:

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. VanIsaac, GHTV contWpWS 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. VanIsaac, GHTV contWpWS 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