Module talk:Unicode chart: Difference between revisions

Revision as of 18:20, 10 September 2019

Revision as of 19:17, 10 September 2019

Line 83:

*1. Consistency of format, avoidance of stupidity like {{diff3|632122404|this}}.

*2 (and 3). [https://i.imgur.com/WuSuoAT.png Here are] four profiler outputs for the [[Template:Unicode chart/testcases|testcases]] page. Note that this is the total churning of five {{tl|unicode chart}}s transcluded on the same page (indirectly through the {{tl|test case}} template/module in fact). Even with those factors the processing stats are at a small fraction of allowable limits in every case except for <code>ifexist</code> (which should probably be the first feature taken out). Actual overhead in the wild would be lower. Based on the percentagepercentages at the bottom, it looks like the single worst bottleneck is the grand <code>#switch</code> statement at [[Template:Script]]. We could probably save at least 40% on parser juice by skipping that and moving its fairly trivial functionality (that of choosing a css class and a [[Template:Script/styles hebrew.css|definition for same]], having already obtained an ISO 15924 code from [[Module:Unicode data/scripts|here]]) into some module.

*4. Keeping a count of reserved codepoints and rendering the "note" as plural/singular/blank will be a trivial step. I just didn't think of it. I do question whether the footnote system is the appropriate way to present this.

*5. My first version of the module actually did have a parameter accepting whole refs. I just took it out when I got the impression every existing template had the same two notes. I can put it back.

*6. Preview of <code><nowiki>{{tl|unicode chart|name=Arabic Presentation Forms-A|version=12.0}}</nowiki></code> has them showing up as normally reserved codepoints (the default assumption based on [[Module:Unicode_data/names/00F|lines missing from here]]), rather than choking. If we want to give themthe "permanently reserved" codepoints a different background and auto-generate a footnote explaining what this means, we'd have to maintain a list of them somewhere. Does anything like this occur in any other blockblocks?

*Also 6. I'd be more immediately concerned about this cell-stretching monstrosity at [https://i.imgur.com/QzF7oVa.png U+FDFD], which seems to be a consequence of using {{tl|script}} in places where the original chart template does not.

*7. Not sure yet. I did see some interesting suggestions [https://stackoverflow.com/q/26407896 here].

*8. Depends on what the rationale is for drawing these boxes, and whether it can be detected in any way from Unicode data. Or whether it needs to be listed elsewhere as a special case. Or whether the boxes are needed at all. I don't see a footnote explaining what the boxes even indicate. No hints [https://i.imgur.com/27jpDrt.png on my own system] either.

*9 and 10. Each of the display-aliased characters in the templates you mentioned returns false for the [[Module:Unicode data]] function <code>.is_printable(n)</code>, except for U+0020 SPACE and U+00A0 NO-BREAK SPACE, which return true for <code>.is_whitespace(n)</code>. So both of these traits can easily be tested. Choosing the replacement alias we want would require maintaining a list of same. I'm not sure a printable space character should be aliased in this manner. Maybe it the cell background should be a different color with a footnote explaining yes, a whitespace character is there, and yes, you can copy it and paste it elsewhere. Also not sure "XXX" is appropriate for U+0080–0081. Maybe we want to display "PAD" and "HOP" instead?

*11. The existing chart for Javanese shows up with a cell height of 80px which seems excessive for the apparent line height of 33px [https://i.imgur.com/z0fgysQ.png on my screen]. Preview of module output for Javanese [https://i.imgur.com/EVWG2xM.png looks fine]. Better in my opinion. Maybe I just don't have the right fonts installed. But yes, cell height/width params can be added if there's a demonstrated need for this. Otherwise the browser should be trusted to stretch cells for large characters as needed. See "Also 6" above.

*12. I think if they are going to be linked, they shouldn't be piped to something else unless the character itself an [[mw:Manual:$wgLegalTitleChars|illegal title char]] and even then it shouldn't be linked to anything other than a title that paraphrases said character (e.g. <code><nowiki>[[Number sign|#]]</nowiki></code>). Making [[≅]] a disambiguation page (then piping the link to avoida more specific topic because linking to a disambiguation page)pages is bad) was a mistake in my opinion. And nothing on these tables should link to wikt. If the character title is a redirect to some other page (such as a list of emojis, or an article about the subject represented by some symbol), that's fine. Someday itthe character itself might become a separate article, which is also fine. The template need not know or care about that. I'm thinking a list of link aliases for bad-title chars (mapping <code>'#'</code> to <code>Number sign</code> and so on) would be a good solution. But only if we're going to be linking themthe characters at all, which is unclear.

*13. I did keep the optional start/end parameters, because I figured subdivision would be wanted in some blocks for reasons including hugeness. Note that these need not be multiples of 16. The module will pad leftover cells accordingly with <code><nowiki><td class="excluded"></nowiki></code> which is currently styled the same as <code>class="reserved"</code> but this can be changed.

*14 and 15. If the unicode block display names can't be made to exactly match the [[Module:Unicode data/blocks|"official" names]] in all cases, we'll need a (hopefully short) list of aliases. Adding a blocknamelink parameter which continues to default to <code>Blockname (Unicode chart)</code> if empty would be easy and sufficient. Let's try to avoid having three sets of names thoughwherever possible.

*16. I don't see why not. See 13.

―[[special:contributions/cobaltcigs|cobaltcigs]] 18:20, 10 September 2019 (UTC)