Content deleted Content added
BabelStone (talk | contribs) →Comments: add my replies inline |
Cobaltcigs (talk | contribs) bullets |
||
Line 54:
===Update/to-do===
''See [[Template:Unicode chart/testcases]].''
*I've reduced the number of required parameters to only the name of the block and the version string. In reality, the former can probably be deduced (from the name of the calling template), and the latter should be exposed by [[Module:Unicode data]] in some fashion (to avoid hard-coding 12.0 on any other page) and should be
*I've got it looking up the [[ISO 15924]] and using that to select a <code><nowiki><span></nowiki></code> from [[Template:Script]] containing a css class for an appropriate <code>font-family</code>. Better would be a way to apply the <code>class</code> and <code>dir</code> attributes directly to the <code><nowiki><td></nowiki></code> element.
*Start/end codepoints still exist as an option. The looked-up values can be overriden to subdivide a large block without confusing the module.
Line 81:
# Will the new approach be used for the list charts that make up [[List of CJK Unified Ideographs, part 1 of 4]] and [[List of CJK Unified Ideographs Extension B (Part 1 of 7)]]?
[[User:Drmccreedy|DRMcCreedy]] ([[User talk:Drmccreedy|talk]]) 04:51, 10 September 2019 (UTC)
*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 percentage 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 them a different background and auto-generate a footnote, we'd have to maintain a list of them somewhere. Does this occur in any other block?
*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 characters you mentioned returns false for [[Module:Unicode data]]<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 these 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 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 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 avoid linking to a disambiguation page) is a mistake in my opinion. And nothing should link to wikt. If the character title is a redirect to some other page, that's fine. Someday it 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 would be a good solution. But only if we're going to be linking them 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.
*14 and 15. If the display names can't be made to 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 though.
*16. I don't see why not. See 13.
―[[special:contributions/cobaltcigs|cobaltcigs]] 18:20, 10 September 2019 (UTC)
| |||