A character in Unicode, can be used in multiple scripts. So in Unicode, that single character gets the script id: 'common'. All fine But a set of characters like 'arabic script' is looking the other direction: for a script it does not matter if a character is used elsewhere. All chars in the arabic script are arabic chars.
The same for inherited characters: they belong to the arabic script, full stop. There is no need to note that they may be used elsewhere.
@DePiep: I'd agree with your usage of 'script' if this was an infobox on the Arabic script or language page but this is an infobox specifically for a Unicode block. The script value(s) are taken directly from the Unicode Standard and are also reflected on the Unicode block page. Script has a very specific meaning in the Unicode Standard. The Unicode block infobox has a parameter for 'Major alphabets' which I think is being muddled here with the script parameter. Apart from 'Major alphabets' and 'Note' fields all the information in the Unicode block infobox comes from the Standard itself. I don't want to be the arbiter of the script value for each block... I think it should come from the Standard. I can already envision the arguments over Assamese vs Bengali if we can't point to a definitive source for the script value. If we go down to the character level there's bound to be an argument over whether U+067E ARABIC LETTER PEH is Arabic or Persian as Wikipedia describes it as Pe (Persian letter). DRMcCreedy (talk) 00:26, 28 August 2014 (UTC)[reply]
I don't want to be the arbiter - you are right, we cannot have OR. And indeed, some characters in this block have 'common' or 'inherited' for script. Still, I think the Standard has more information that just the script code (which gives one script per character). For example, the name can contain the script name: U+06DAۚARABIC SMALL HIGH JEEM has script code 'inherited' (being a diacritic), but we can conclude that it belongs to the Arabic script (conclude from name and inherit properties). For 'common' script we again can look to at the name, and check other scripts; (e.g., the numbers). Note that 'Persian' script is not defined in Unicode. Still, if we research the whole block, there still can be characters we can not attribute to 'Arabic', so the problem might not be solvable. Btw, your U+067E example is a bad Wiki naming, in Unicode it is defined Arabic. -DePiep (talk) 12:11, 30 August 2014 (UTC)[reply]
Are you then OK with me synching the Standard's script names with the Unicode block articles? I would always note Common and Inherited after any specific script names. DRMcCreedy (talk) 18:00, 30 August 2014 (UTC)[reply]
Yes, go ahead. That would be factually correct by the source. I was just freewheeling on how to make it more precise. But my algorithm here is not finished. (By the way, do you know this site? It nicely adds "Persian, Urdu, ..." for U+067E). -DePiep (talk) 18:39, 30 August 2014 (UTC)[reply]
@DePiep: I've had a look and here are my suggestions:
I like the V-T-E but think the title is much too large and competes with the section headings. I tried out a few sizes at User:Drmccreedy/sandbox4 purposefully using "Unified Canadian Aboriginal Syllabics Extended" because it's currently the longest block name. "small" is my favorite font size. "smaller" could work but I still think it distracts from the headings and text.
I like moving the official chart link to the footnotes. I think using "Unicode code chart" for the link is too vague because it appears inside a Unicode code chart. I'd leave the wording "Official Unicode Consortium code chart". I seem to remember a heated discussion over "official" and think this wording was the compromise. In any case I think we should always make it footnote #2 because we'll always have #1 for version and #2 for the official chart.
Ref names containing spaces, like {{ref label|Chart U2600|2}}|...}}, do not work. Clicking on the [x] number no longer takes you to the reference.
Lastly, For the title wording you have "Unicode chart BlockName" instead of simply BlockName. While it works, I think it's redundant to have "Unicode" to the title because the template's likely to be in a section that already mentions Unicode and the word will appear at least twice in references/notes at the bottom of each table. I tried a few different wordings at User:Drmccreedy/sandbox4 for the title. "Chart for BlockName block" is my favorite (even though you could say "block" is also redundant) followed by "Chart for BlockName" but in reality any would work. It's that balance between explicit and concise. I'm also keeping in mind Unicode chart templates with the subset feature like Halfwidth and Fullwidth Forms at Katakana#Unicode. It would be nice if any new title syntax easily allows the subset to be noted, like "Chart for foobar subset of the BlockName block" (for example, "Chart for katakana subset of the Halfwidth and Fullwidth Forms block") or "Chart for foobar subset of BlockName" ("Chart for katakana subset of Halfwidth and Fullwidth Forms"). DRMcCreedy (talk)
First: I've added some links & sandboxes, for us to play. I'll do my demo's in the Math one (guess what's yours).
re 1.a. Yes, the small font is best. End of problem.
re 1b. But it is a simple table title, so it should be bold. (This looks bad now, because the table is made "font big" for the characters, but it spoils the title. See Miscellaneous Symbols/sandbox below for my proposed changes). My solution is: the characters can be big, but the table top should be regular.
re 2. Yes, that chart link should be in the footnote. OK then, it's just a link.
But no, no need to call it "official". (I was the one who heated up the discussion about this; I still claim that "official" wrt Unicode is weasel wording. Unicode does not have anything not official.
re 4. Title wording. Yes, this is not straightforward. I'd say, the table shold be self-contingent (not relying on text surrounding). So somehow it should mention 'Unicode'. Maybe "Miscellaneous Symbols (Unicode chart)"?
We'll need the first codepoint parameter for both the header and the footer in order to create unique ref labels. It's currently called "block id" in the header template but I'd suggest using something like first or start in part because I don't trust spaces in parameter names. For that reason I'd go with name instead of "block name", grey instead of "has grey" and extranotes or notes instead of "extra notes".
I don't think we need a version parameter on the header, just the footer. Shouldn't have to change it in two places each time Unicode releases a new version.
Distraction
I see the dates for the cite of the Unicode chart being problematic. It's another thing we'll have to change for each release. Same with retrieved date. We might have the template add it based on version number.
Distraction
We'll only need to repeat the block name for the footer if we use it for the cite. Generic wording would avoid this parameter.
Distraction
I'm assuming "extra note" would just add the passed text as-is after the two standard references, right?
Distraction
Is there a way to have the reference numbers automatically generated within the chart instead of hardcoding them as we do today?
I don't know, will take a look.
Visually I don't like "(Unicode chart)" in a different font size. I think it would look better if the title was in a consistent font size. DRMcCreedy (talk) 22:19, 30 August 2014 (UTC)[reply]
We disgree. I like the block name being in bold (after all, it's the table title), and have the Unicode mentioned. It's my text proposal for the title.
Distractions: I started the templates {{Unicode chart/header}} and {{Unicode chart/footer}}, but of course they only will reproduce what we agree (wish I had not mentioned them). Template technicalities are a distraction. Please let us focus on the visual outcome, on what we show in mainspace. E.g., I'd like to see your suggestions in here. It's free. -DePiep (talk) 22:39, 30 August 2014 (UTC)[reply]
The title is bold and identifies it as a Unicode block
I removed the ref numbers. We'll always have at least two notes and all the notes have ref numbers just on the title so the numbers seem superfluous and distracting.
I agree this discussion should move to the template talk page for a wider audience.
Yes, looks good. I changed the cellspacing from 5px to 2px (as a suggestion); but width settings are still active. Do you think the character should be larger (say 150%)? And should we reduce whitespace (cell padding & widths)? -DePiep (talk) 09:52, 31 August 2014 (UTC)[reply]
@DePiep: I'm not sure if it's just my computer but I don't really see a difference between 5px and 2px. In fact, removing border="1" cellspacing="0" cellpadding="5" and just relying on class="wikitable" seems about the same to me. If it does to you as well maybe we can just leave it up to wikitable.
The character size is currently set to "large". Looking at the manual of style using a percentage, like 150%, might be a better way to go. For me 150% and large are quite similar, at least for this block. No doubt thanks to varying fonts for different blocks some look quite large, like Phags-pa and some quite small, like Mongolian. 150% seems fine.
I think the width is important to keep for visually consistent columns. It doesn't make much of a difference for this block but I remember that some looked terrible without it. DRMcCreedy (talk) 23:42, 31 August 2014 (UTC)[reply]
Yes, let's see what happens when we leave it to basic class="wikitable" (It's not about your browser). Note that there is also this width setting, per column in the hex-numbers row (2nd row): style="width:20pt". So these set column width (too; it is co-affecting). In Template:Unicode chart Miscellaneous Symbols/sandbox I've removed them, to see the effect.
So, as for whitespace we are still playing around. I don't know what looks best, but we should know the control options (there are more than those mentioned). I prefer the number ("150%") above the "large" wording option to have more control, see below.
About font size. When set in the table top row, the font-size:150%;, this applies to the whole table. But this should only be for the characters, not for headers &tc (we already concluded). So setting to regular size is done by style="font-size:67%" (150% × 67% = 100%). For now, I think we should use this to set the sizes for regular text (not the Unicode characters it is about).
Not applied: adding a row-header sign (! instead of | pipe). Will bolden the cell text. All these are applied now in the Misc Symb sandbox mentioned .
In a separate research, I am looking to get these replacement characters show more nicely: NBSP. Should not influence this topic here (must flow nicely in the chart tables). -DePiep (talk) 09:59, 1 September 2014 (UTC)[reply]
Yes. Do you know of any chart table that has irregular column widths, today?
If I am correct, we are looking for the right amount of whitespace:character_size at the moment. It takes some patience, but I promise we can control the lot. I also note that page-layout designers love whitespace (at wikimedia , and enwiki pagelayout setting etc), so maybe our outcome will look like ... the current live view.
If we are going to list all scripts associated with a given Unicode block (which I think is a good idea), then maybe we should parenthetically indicate how many characters in the block belong to each script, otherwise the list of scripts may be misleading to the reader. e.g. for Tibetan: "Tibetan (207 characters), Common (4 characters)". What do you think? BabelStone (talk) 10:12, 14 September 2014 (UTC)[reply]
Great. I'm going to be too busy over the next three weeks to be able to spend much time with this or any of my other suggestions, but I'm always available to help out if needed. BabelStone (talk) 19:15, 14 September 2014 (UTC)[reply]
Chart view vs List view for Unicode blocks
The Unicode block code chart templates give a good visual overview of the block (if the font stuff works!), but is unsatisfactory in many other ways. I have been thinking that in addition to the visual chart view it would be useful to have a list view of assigned characters in each block that provides all the hidden details about the characters. Maybe we should have a button on the Unicode code chart templates that expands the code chart view into a list view (list view hidden by default), with the code point, character name, script, general category, etc. for each assigned character in the block listed in a table. You wouldn't want it for the CJK unified ideographs and Hangul symbols blocks, but I think it would be very useful for other blocks. BabelStone (talk) 10:18, 14 September 2014 (UTC)[reply]
This should be useful. Here are the first things that come to mind:
Can it include derived age and annotations (from NamesList.txt file)? I'd hope for a separate column for derived age but annotations and other notes could be included with the character name on a new line.
Derived age is definitely useful. I'm not sure if there is enough room for annotations, and if you add annotations and notes from NamesList.txt then random editors are going to start editing these notes and adding their own. There is also copyright issue for the notes which I think would preclude us including them. BabelStone (talk) 19:12, 14 September 2014 (UTC)\[reply]
Should we remove the pop-up information for each character once this is in place? Or would we leave that duplicate information (codepoint, name, alias)?
I think yes. The pop-up names are far less useful now than they used to be because a few editors have been keenly (over-keenly in my opinion) adding wikilinks to as many characters as possible, and unless you carefully position your cursor in just the right position the Wikilink target name appears instead of the popup names. BabelStone (talk) 19:12, 14 September 2014 (UTC)[reply]
Would that size of the data be an issue for larger blocks?
Possibly. I would leave out CJK Unified ideographs and Hangul syllables (and any future blocks with algorithmic names such as Tangut and Nushu), which would mean the largest block would be Yi syllables with 1,165 characters which may or may not be too long. For CJK unified ideographs etc. we could just have two rows for first and last character in the block. BabelStone (talk) 19:12, 14 September 2014 (UTC)[reply]
I hope not. I think we should restrict ourselves to the most useful properties, and avoid mission creep by adding more and more properties just for the sake of being complete. I would say that character name, formal aliases, general category, script, and derived age are very useful; but combining class category, bidi class, decomposition type/mapping, numeric type/value, case mapping, etc. are not essential and should not be included. I would also avoid repeating the actual character shown in the chart template. BabelStone (talk) 19:12, 14 September 2014 (UTC)[reply]
I think it is wrong, or at least inefficient, for us to be maintaining so much Unicode data for scripts, blocks and characters by hand on en:wp. Such data is needed by all the big wikipedias, but at present it needs to be duplicated for each language version of an article or template. It seems to me that it would be best to maintain Unicode data on Wikidata so that it available to all Wikimedia projects independent of language. Perhaps this would mean Wikidata entries for each Unicode script, each ISO 15924 code, each Unicode block, and each and every assigned Unicode character. I've never used Wikidata so don't know how we would go about doing this, but it is something I think we should try to consider. BabelStone (talk) 10:31, 14 September 2014 (UTC)[reply]
I agree, especially if we expand the amount of data for "list view". I'm not familiar with Wikidata either but it would be good to look into it further. DRMcCreedy (talk) 16:31, 14 September 2014 (UTC)[reply]
Yes, might be worth trying to involve someone who is involved with Wikidata. I don't think it's urgent, and I have very limited time for Wikipedia at present, but perhaps we can do something about it over the next year. BabelStone (talk) 19:19, 14 September 2014 (UTC)[reply]
Actually this is not what Wikidata does. It does not store central data, but only connects same topics across wikis. Simply, it replaced interwiki links. e.g., Moskow (this enwiki) de:Moskau and ru:Москва now all link to wikidata:Q649, the non-language coded id for this object (the city).
You are right. Language-free data, so fit for core Unicode. However, that is long term. Last time I tried it was not even possible to simply retrieve exisiting data from wd (to use in enwiki).
I get what you're saying about chart headings (uniformity is nice), but faced with 3k/9k of redundancy, which accounts for over ⅓ of the documents at present, is it really that big an issue that the chart headings display in the same font as the rest of the row? Maybe bandwidth usage/optimization doesn't matter to most people, but there's the maintainability issue, too. If a new supporting font comes along, it's a bunch easier to change 𝒳 styles than 16𝒳 styles. The sad part is, if we could add a single line to a global stylesheet (e.g. "table.unicodeChart > tbody > tr > th { font-family:whatever;}" — or td:first-child instead of th, depending on the markup), consistency could be enforced throughout WP for those headings while keeping life easier for ordinary editors. ⇔ ChristTrekker13:54, 27 August 2015 (UTC)[reply]
I don't see 6k as a huge waste of bandwidth especially considering the size of the images in the article and the relatively small number of times the page will be viewed. If preserving bandwidth is the goal we could trim a little from the most popular articles in Wikipedia and accomplish far more savings.
Many other Unicode templates, like Template:Unicode_chart_Balinese, employ the same style: headings in the default font of the user and non-Latin characters using a list of fonts. Are they all to be changed? What should we do with the fonts that don't have Latin character support? Exclude them as an option?
If maintainability is the goal we can add style temples for a given script. For example, Template:Unicode_chart_Bamum, which has a single template that lists the fonts. That way to add or remove a font you change it only in one place. But that doesn't address your bandwidth issue.
I agree that a td level default setting would be great, it's just not there. An even better one would be a "skip adding style to this cell". DRMcCreedy (talk) 15:28, 27 August 2015 (UTC)[reply]
Rewriting Cirth
«Your draft article on cirth is a great improvement over the existing article.
I'd like to encourage you to publish it. DRMcCreedy (talk) 15:06, 3 October 2015 (UTC)»
I see that you are doing good work with the Unicode templates... I do have one question/concern, however. I happened to stumble across your latest edit to Template:Unicode chart Greek and Coptic, if I may use that as an example. I see that you removed the following "boilerplate" comment:
<!-- PLEASE ADD THIS TEMPLATE'S CATEGORIES TO THE /doc SUBPAGE, THANKS -->
and replaced it with the category:
[[Category:Unicode charts|Greek and Coptic]]
Can I ask your rationale for doing so? Are you attempting to categorize the template itself, or pages that utilize said template? As best as I can tell, this practice will cause several undesired effects. Please see WP:CAT#T and WP:TCAT, which recommends against this approach for several reasons. Given that you are updating many, many templates, I fear that this might inadvertently be creating a lot of cleanup work for someone.... Thoughts? Thanks! —grolltech(talk)17:44, 2 February 2016 (UTC)[reply]
@Grolltech: My only intention was to make those four templates (Unicode chart Halfwidth and Fullwidth Forms, Unicode chart Greek and Coptic, Unicode chart Enclosed Alphanumeric Supplement, and Unicode chart Enclosed CJK Letters and Months) like the other 260+ Unicode chart templates. The other templates have their names in the Category (with a few exceptions). It is done within a noinclude tag so maybe the issues noted at WP:CAT#T and WP:TCAT don't apply. I honestly don't know. DRMcCreedy (talk) 20:21, 2 February 2016 (UTC)[reply]
@Grolltech: After some research I’m pretty sure the noinclude tag makes the category apply only to the template, not the articles it’s transcluded into. If I’m wrong let me know and I’ll fix any issues. Thanks. DRMcCreedy (talk) 16:21, 12 February 2016 (UTC)[reply]
Unicode blocks history section
Hey there, I am super excited to see your efforts on adding the history section to Unicode blocks. I would like to share my opinion on the style of the table. The current tables are sortable, and looks like the following
(1) If you actually sort the table by any column, say, Version, then the vision effect is not good, and you cannot revert back to the original table by any means.
(2) The width of the table should be adjusted. If you look at Kannada (Unicode block), you'll immediately see what I mean.
It is unsortable, with the Version column placed at first. Some columns have fixed width: Version = 60, Final code points =180 (so if there are many sections, this column will not be too wide), count = 70, L2 ID = 95 (good for the doc ID length), WG2 ID = 65, Document no width restriction. Of course the width may be fine-tuned depending on the case. The count column records the total number of code points, as well as the number of newly added ones.
I certainly agree that Drmccreedy has been doing an amazing job of documenting the history of Unicode blocks, and it is a really important contribution as there is nowhere else on the internet where this information is available in this format. As to the layout of the table, I agree that sorting is not really necessary, and as the rows are ordered by version it makes sense to put the Version column first, so I support the table layout suggested by Sofeshue. BabelStone (talk) 09:29, 10 April 2017 (UTC)[reply]
@Sofeshue:@BabelStone:I'm glad my hard work is being appreciated. While scriptsource has some of the same information it's incomplete and usually not available at the code point level. On the sort issue... The rows aren't ordered by version, they're ordered by code point. Cyrillic is a good illustration. Envision someone trying to find out why/how code point U+04FB was encoded. The task of finding the right document is harder if the table is sorted by version. If the goal is to determine the code points added in a given release, I can easily create a small, separate table that lists the code points by release. Sorting the document numbers is useful, at least to me, because they don't always go in date order. If I'm looking at a list of doc numbers it's easier for me to find them in the table if I can sort those columns. While I'm not keen on changing the column order or removing the ability to sort them, I'm in total agreement that browsers do a lousy job determining an aesthetically pleasing column width for this data. I think the main issue here is the size of the code points column. I can limit the size of that column based on the size of the data but should it be a fixed number or a percentage? For example, 25% or 180px? My concern is accessibility. What if someone has a large font size. Does the display still work with fixed pixels specified? If the code points column is subdued, is there any reason to impose limits on the document id columns? DRMcCreedy (talk) 17:17, 10 April 2017 (UTC)[reply]
There does seem to be an issue with the L2 ID wrapping because of the dash. A few people have added a non-breaking dash but that makes "find" stop working. I think the most sensible solution is for me to wrap individual L2 IDs in {{nobr|...}}. I can do this for all the block histories once we figure out the desired width of the code point column.DRMcCreedy (talk) 19:52, 10 April 2017 (UTC)[reply]
I don't mind keeping the sorting property.
I feel sorting by version is better. Let's still take Cyrillic for example. The final code points column is taken out and an index column is added (the table below). Suppose I want to find U+04D8. I need to scan the code ranges from the first row. When I reach the end of row 7, with code range 04EC..04ED, which is greater than 04D8, can I conclude that 04D8 is within the first seven rows? No. It appears in the 9th row. The problem is, although the starting codes in the columns are increasing, we cannot guarantee that the starting code on the (n+1)th row is larger than the ending code on the nth row. If we sort by Version, for each version, order the codes in each version by an increasing order, then the starting codes in the columns are still in increasing order, and the starting code on the (n+1)th row may still fail to be larger than the ending code on the nth row. To sum up, the two sorting methods essentially have the same property on the Code column, but sorting by Version is furthermore clearer on the Version property, thus it is better. I hate to use such mathematical language on computer science... :-) Sofeshue (talk) 08:49, 11 April 2017 (UTC)[reply]
Wow, I didn't know of {{nobr|...}} before, and it does solve the L2 ID, WG2 ID columns. I did an experiment, one just adds it to the LONGEST file name in L2 ID and it suffices. As to the Final Code points column, what about this method: add a <br> every two sections. For example:
U+0401..040C, 040E..044F, 0451..045C, 045E..0486, 0490..04C4, 04C7..04C8, 04CB..04CC should become
I strongly think that ordering the tables by version is best, as a common scenario is users trying to work out what additions were made in which version and why. If someone wants to find out more about a particular code point then it is not hard for them to find the code point in the Final code points column. I still do not think that sorting is necessary in these tables. BabelStone (talk) 08:57, 11 April 2017 (UTC)[reply]
I did a manual mockup for Cyrillic. I think it incorporates all the changes discussed. I kept the width=180 instead of using br's because that seems cleaner. I'll only set the width if we have a long range of code points. @Sofeshue:@BabelStone:: If this meets everyone's requirements I'll retrofit the existing histories using this format.DRMcCreedy (talk) 16:48, 11 April 2017 (UTC)[reply]
Everson, Michael; Birnbaum, David; Cleminson, Ralph; Derzhanski, Ivan; Dorosh, Vladislav; Kryukov, Alexey; Paliga, Sorin (2006-10-30), On CYRILLIC LETTER OMEGA WITH TITLO and on CYRILLIC LETTER UK
Cleminson, Ralph (2007-01-19), Comments on Additional Cyrillic Characters (L2/07-003 = WG2 N3194)
^Proposed code points and characters names may differ from final code points and names
That's good enough. One minor point, should we record the total number of codepoints and the number of newly added ones? For example, in the above table, Version 1.1, column 3, 38 ---> 226 (+38). Sofeshue (talk) 17:16, 11 April 2017 (UTC)[reply]
After several hours I determined that width has to be on each and every table data row for Edge to honor it! br does work on Edge but the forced breaks get weird when the screen is resized so I'm going with width. I'll also use the nobr template for all IDs that can split. I played around with only doing it on the longest ID and it's time consuming and problematic so I'll put it on all IDs with dashes. I'll update the tables now. DRMcCreedy (talk) 21:13, 12 April 2017 (UTC)[reply]
Damn, how can you be so fast bro? There can be some minor improvement though. E.g. Hatran, the Code column width should be a little large to accomadate two sections. Sofeshue (talk) 03:46, 13 April 2017 (UTC)[reply]
I'm not sure how much time I'd spend customizing each block because the output isn't going to look the same for everyone. For example, if I make the Hatran code point column large enough to fit on one line, the document citation wraps to a second line (based on my normal window size). I suspect it might fit all on one line for you based on your suggestion. But if you feel there's a compelling reason to change some of the widths go ahead and update them. I'll add exceptions to my scripting so that I don't overlay them with the old width values if/when I add new documents to a given block. DRMcCreedy (talk) 06:34, 13 April 2017 (UTC)[reply]
I realized that it must be the default font thing. I think on your browser, Hatran Code column folds after the second section, but on mine, it folds at the first and the second (so three lines), leaving a white space of about half of the width. I don't have any custom .css and I use the system default font (Arial) at default size (10.5), which is the font I believe most people use. I'll do some experiments and do fine-tunings to the width if necessary. Sofeshue (talk) 07:04, 13 April 2017 (UTC)[reply]
You can use this user right to perform maintenance, answer edit requests, and make any other simple and generally uncontroversial edits to templates, modules, and edinotices. You can also use it to enact more complex or controversial edits, after those edits are first made to a test sandbox, and their technical reliability as well as their consensus among other informed editors has been established. If you are willing to process edit requests on templates and modules, keep in mind that you are taking responsibility to ensure the edits have consensus and are technically sound.
This user right gives you access to some of Wikipedia's most important templates and modules; it is critical that you edit them wisely and that you only make edits that are backed up by consensus. It is also very important that no one else be allowed to access your account, so you should consider taking a few moments to secure your password.
If you do not want this user right, you may ask any administrator to remove it for you at any time.
If you were granted the permission on a temporary basis you will need to re-apply for the permission a few days before it expires including in your request a permalink to the discussion where it was granted and a {{ping}} for the administrator who granted the permission. You can find the permalink in your rights log.
Hi Drmccreedy, per Special:PermaLink/859447525 I've added this access for you. Please be sure to review the information above carefully. While this lets you bypass protections, ensure that you act carefully - especially if you want to branch out in to areas you have never edited such as luascript modules. If you are in doubt of an edit to a highly used template, after sandboxing and testing, filing an edit request for someone else to review is the best course of action. Best regards, — xaosfluxTalk03:27, 14 September 2018 (UTC)[reply]
Now my question is: How can I fix wrong ISO code redirects myself? Or, in case I am not authorized to do so: Where can I report wrong ISO redirects? Love —LiliCharlie (talk) 16:40, 5 October 2018 (UTC)[reply]
@LiliCharlie: Here's how I'd do it: When you click on ISO 3166-1:NL you'll end up redirected to the Netherlands article. Notice it says "(Redirected from ISO 3166-1:NL)" just below the article title. Clicking on the ISO 3166-1:NL link takes you to the redirect itself (automatically using &redirect=no in the URL). Click "edit this page" just like a normal article. In this case, you would change #REDIRECT Netherlands to #REDIRECT Kingdom of the Netherlands. I don't know if there are edit restrictions but that may vary by the redirect and the user. Give it a try. I don't think there's an "official" place to report ISO redirect problems but if you're unable to update them, let me know and I'll give it a try. Thanks for improving the accuracy of Wikipedia. DRMcCreedy (talk) 17:03, 5 October 2018 (UTC)[reply]
for fixing up all the Glottocode and ISO-639 errors. I'm going over them now, and the ISO errors especially are pulling up a lot of other confusion. I think they're mostly caused by page moves or split articles, where the ISO redirects were not fixed to match, so those are usually now wrong too. As are alt-name redirects. — kwami (talk) 04:31, 6 February 2019 (UTC)[reply]
Hello. I am wondering if you have picked the correct glottolog name. The distinction between the Irminones and the other Germanic tribes was only made classicaly in a period before the split into lower and upper west germanic, and so maybe West Germanic is more correct. Of course there is some uncertainty about such an historical term, but this surely seems the most obvious conclusion.--Andrew Lancaster (talk) 07:05, 3 April 2019 (UTC)[reply]
Hi @Andrew Lancaster: I was just matching the existing Glottolog code in Wikipedia to the name used in the (latest version of) Glottlog. (high1286 = Upper German and high1287 = West Middle German.) Unfortunately I have no idea if those are the right codes to use in the Infobox. There is a Glottolog code for West Germanic (west2793). You could use that instead if it's more accurate. DRMcCreedy (talk) 15:09, 3 April 2019 (UTC)[reply]
Hi, one thing which I have been thinking about for a long time (several years) is to make the Unicode code chart templates expandable to show a list of all character names (and formal character name aliases). I think this would be very helpful to users as at present the only way to know what the character name is is to hover the mouse over the character cell whilst carefully avoiding hovering over the link that people so love to add to the characters; but the mouseover text is not copyable, so it is of limited use. I have made a rough mock up of what I mean in my sandbox. What do you think? Please feel free to tweak or improve it. (I suggest that this approach is not applied for large blocks with algorithmic names). BabelStone (talk) 20:42, 22 August 2019 (UTC)[reply]
@BabelStone: I think it's definitely doable if you think it's useful. And if you've been thinking about it for that long it's probably useful.
I changed the "Character names" title to "List of character names" to be painfully clear.
It is better.
Should the list be sortable? This involves adding a header. I've mocked it up in your sandbox. I'd skip this on the algorithmic ones though because the code point and name always sort the same.
Personally, I don't think sortable is particularly useful, but I don't mind.
I'm assuming aliases will use the same format as the current charts: FOO (alias BAR)
Seems reasonable.
Can we agree that there should be NO LINKED CHARACTERS in that lists? If someone wants to link each character they can do so in the existing part of the chart as far as I'm concerned. Latin Extended-B is an example of this.
I full agree that there should be no links in the names list.
There's likely to be some duplication between the template and the article text. Latin Extended-B again is a good example. I'm thinking that article text with a list of characters can be removed once this is in place so long as they don't add additional information. (I would count the decimal values provided in Latin Extended-B as not adding information except to anyone who doesn't know you can use &#xHHHH; notation.)
Yes.
Lastly, do we need to worry about added character counts for articles that include multiple charts? Could this cause them to exceed size limits?
Probably not because articles with multiple code chart templates are generally not for very large blocks, and the huge blocks with algorithmic names will only have a slight increase in size.
I definitely think it is useful. If users want an overview of the character names, at present they have to click on the link to Unicode code charts or go to another website. (Other replies inline above) BabelStone (talk) 10:53, 23 August 2019 (UTC)[reply]
I made the ogham table sortable, but when you sort by code point it does not sort in the expected order (hex values with A..F are sorted separately from hex values comprising 0..9 only). We could overcome this by putting the code point in a {{sort}} template with a fixed width decimal value for the hidden sort parameter, but this seems like too much trouble for a marginally useful feature. BabelStone (talk) 11:06, 23 August 2019 (UTC)[reply]
For blocks with algorithmic character names I think best to only list first and last assigned characters in the block. I currently put "..." between the two rows -- is that OK, or is there a better way of indicating omission of the intervening rows?
I noticed that and thought it was intuitive.
Many or most blocks have hard-coded fonts applied (in the template or using css) to the code chart glyphs (which I personally don't like). For the names list it is useful to put the character after the code point, but I don't want to hard-code the fonts to use, so I was thinking of not specifying fonts for the names list part of the table. What do you think?
I'm OK with this but anticipate others will want to add font info. I'd say let's leave font info off for now and see if there's push back.
Do we want to add any other core data for the characters? For example, we could provide a column for general category or script. Is that perhaps overkill?
I thought of that too. Probably overkill. My concern is there's almost no end of info we could add.
Should the List of character names go above or below the Notes? I'm happy with current placement below the notes, but maybe it makes more sense to put the notes at the very bottom.
I like the notes at the very bottom logically, but the list is probably easier to spot if we don't wedge it between the chart and the notes. So let's leave the list as the last item.
Thanks for all the feedback. I think we're about there now, but I don't want to rush into making quite a large change to a large number of templates, so I'll sit on it for a week or so in case you or me or anyone else has any suggestions for improving how we do it. BabelStone (talk) 20:05, 23 August 2019 (UTC)[reply]
Sounds good. The only other question that's popped into my head is combining characters. Often in the chart we'll use a dotted circle (◌) or a space with them. I'm thinking if the purpose of the table is copy-and-paste, maybe we should skip that. Not sure I feel strongly either way but that should be nailed down before the charts are created. DRMcCreedy (talk) 20:43, 23 August 2019 (UTC)[reply]
I've added an example for a block with combining characters (Combining Diacritical Marks for Symbols), with plain characters for the first row and prefixed with nbsp for the second row. The unprefixed characters do not look good as they straddle the code point column, so I think prefixing with nbsp is best (I don't like the dotted circle as that often interferes with the combining mark, and makes it difficult to see clearly). BabelStone (talk) 11:24, 24 August 2019 (UTC)[reply]
I'm sorry to say you this but i don't feel right about the latest version of the roadmap. It is not as representative since e.g. South Asian and Central Asian scripts. I don't feel they are represented the right way and might cause confusion. As such i demand some changes to the roadmap. I'm going to use this reference: [4]
Separate South Asian and Central Asian scripts. The color representative of Central Asian scripts are added back.
The color used for "Notational Systems" in the current version will have to be expanded so can be used for combining marks (Diacritics), Punctuations, modifier letters, and notational systems. Because of this color key will be renamed "Systematic characters". What i mean by that is these characters aren't essentially symbols but systematic. This will be applied in BMP and SMP roadmaps.
The color used for "Linguistic scripts" will be used for Specials, C0 and C1 control characters. This color block will be named "Control characters", since they are used for the system. This will be expanded to the Variation Selectors and Variation Selectors Supplement in the Plane 14 (under different name of Variation Selectors Supplement) to conserve space as well as because they are control characters too. Take a look at Unicode control characters for the reason.
Because Variation Selectors had to use new colors, i had to say that color previously used by Variation Selectors in Plane 14 might had to be reused for a new style of script (Ideographs). Please note that Ideographs are separate from CJK Ideographs. Any characters that can't be considered CJK but ideographic will be included in this key. Anyways, this key will be uses in the Plane 1 and beyond. For example, Linear B ideograms. As more ideographic scripts are added in the future, this will be also expanded along with the addition of these scripts.
Reverted note. It's useful but misplaced. It should be in one of the articles that includes that chart. Individual characters aren't footnoted and if they were, there would be hundreds of footnotes in the charts.
My edit was reverted (Mathematical Alphanumeric Symbols)
Hello! You reverted my edit on Mathematical Alphanumeric Symbols as "reverting vandalism." I was attempting to fix an error (it seems that two pairs of symbols had been swapped). TdanTce (talk) 04:11, 2 January 2020 (UTC)[reply]
My apologies. Vandalism wasn't accurate. However, the table wasn't wrong. You changed U+1D766 to show U+1D767, U+1D7A0 to 1D7A1, U+1D767 to U+1D766, and U+1D7A1 to U+1D7A0... swapping them yourself. Maybe your default font isn't showing them correctly but I've double-checked them in a Unicode-specific editor and they were correct prior to your edit. DRMcCreedy (talk) 04:22, 2 January 2020 (UTC)[reply]
Hi. Yeah, clarified. Unicode only accepts characters that are semantically distinct, and these small caps are graphically basically the same as l.c. and so couldn't be used as distinct symbols. Most of the remaining are found in the lit e.g. as phonetic symbols, at least in tables of theoretically expected symbols. — kwami (talk) 02:48, 25 January 2020 (UTC)[reply]
Hi, Drmccreedy. I thought your edit comment here would be quite correct if the table on that page listed both languages, but in fact it only lists one. It seems to me it makes more sense that the link should take readers to the article about the language that is listed in the table. --R'n'B (call me Russ) 14:05, 15 February 2020 (UTC)[reply]
My issue is that I don't trust the infobox comments on the Bonerif and Edwas pages. Neither are sourced so I think it was just someone's preference to say bnv applies to one and not the other. I should fix the comments in the language articles to say something like "ISO 639 treats Bonerif and Edwas as a single language" but I didn't feel like getting into an edit war with the person who's feels ISO 639 is "confused". Does the single language comment sound right? Then I think the item in the table should be "Beneraf, Bonerif, Edwas" like ISO 639 shows. If those changes are made, I think the disambiguation link should stay. What do you think? DRMcCreedy (talk) 16:16, 15 February 2020 (UTC)[reply]
Well, you're getting over my head now. If ISO in fact lists all three names, then I suppose our table should do the same. In that case, the link to the disambiguation page should conform to WP:D#HOWTODAB. --R'n'B (call me Russ) 21:24, 15 February 2020 (UTC)[reply]
The article will be discussed at Wikipedia:Articles for deletion/EBCDIC 389 until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.
Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article. Fram (talk) 07:04, 23 June 2020 (UTC)[reply]
Unichar
Thank you for finding and fixing incorrect names. But I don't think you need to change lower case names to upper case because {{Unichar}} does that (or more precisely, applies style SMALLCAPS) anyway. Or is there a sublety I've missed? --John Maynard Friedman (talk) 18:12, 30 June 2020 (UTC)[reply]
And "... small black ..." became Unicode's "... black small...". No worries. It's nice to have another pair of eyes checking these things for when I do make mistakes. DRMcCreedy (talk) 19:27, 30 June 2020 (UTC)[reply]
TYVM. I've had a look. I wouldn't expect DePiep to be satisfied with the quick'n'dirty hack. Fancy your chances at fixing the the underlying fault in {{sc}}? If it was easy, anybody could do it, that's why we pay you so much! --John Maynard Friedman (talk) 23:14, 1 July 2020 (UTC)[reply]
Hi Drmccreedy, what would be the correct location to raise changing the footnotes to letters? Category talk pages tend to be rarely used in my experience. CMD (talk) 16:37, 14 August 2020 (UTC)[reply]
@Chipmunkdavis: That's a tough question. And one I should be able to answer considering I raised the requirement in the first place. Both the category talk page and various Unicode templates I checked have fewer than 30 watchers. So there's probably no high visibility spot to put it. I'd say propose it either on the Category:Unicode charts talk page or Template:Unicode chart Tagalog and ping user BabelStone (the only other user that might care). I don't think it will be a controversal change unless there's some technical issue I've overlooking. DRMcCreedy (talk) 17:25, 14 August 2020 (UTC)[reply]
Sorry I may sound rough but it is actually that the written sources are from the 8th century, other source says it is been used since 6th century. So, I hope this may help. Thanks. Beshogur (talk) 20:40, 15 September 2020 (UTC)[reply]
EBCDIC Code page numbers without articles that need to transwiki
The Code page articles missing articles (and have never been created) are Code pages 390, 391, 392, 393, 394, 395, 435, 829, 834, 835, 837, 839, 881, 882, 883, 884, 885, 886, 887, 888, 889, 890, 931, 933/1364, 935/1388, 937/1371, 939/1399, 1001, 1003, 1005, 1007, 1024, 1027, 1028, 1030, 1031, 1032, 1033, 1037, 1068, 1071, 1073, 1074, 1075, 1076, 1077, 1078, 1080, 1082, 1083, 1085, 1087, 1091, 1136, 1150, 1151, 1152, 1278, 1303, 1364, 1376, and 1377. Code page 1279 is also missing an article, but I haven't found any sources for the code table for that code page. You should also look at the reply on Scottywong's talk page. Alexlatham96 (talk) 00:38, 30 September 2020 (UTC)[reply]
The article cites "Mayence 1873" but no such source is listed in bibliography. Can you please add? Also, suggest installing a script to highlight such errors in the future. All you need to do is copy and paste importScript('User:Svick/HarvErrors.js');// Backlink: [[User:Svick/HarvErrors.js]] to your common.js page. Thanks, Renata (talk) 14:38, 4 October 2020 (UTC)[reply]
I suggest you contact other editors of that page as I'm not familiar with the topic. My sole contribution was to fix a language parameter of a template. Sorry. DRMcCreedy (talk) 21:56, 4 October 2020 (UTC)[reply]
I only have access through their online browsing platform (OBP). I'm also signed up for notifications of changes, which come fairly soon after the standard is updated. I've seen nothing on Buckinghamshire. Based on other country changes it can take some time (months) for the standard to adjust to reality. I don't really worry about it much because these articles on ISO 3166 are describing the standard itself while an article like Subdivisions of England should be more up-to-date. If you want, you could add a footnote citing a source and saying something like Buckinghamshire's change to a unitary authority is not yet reflected in the ISO 3166-2 standard. DRMcCreedy (talk) 01:24, 30 October 2020 (UTC)[reply]
@Kwamikagami: I see two issues: First, tr44 (Unicode Standard Annex #44) should be added as a reference. Second, we need a way to clarify that LC doesn't include all the non-bold L rows under it. Maybe something like "L, Letter; LC, Cased Letter (Lu, Ll, Lt only)<ref>". What do you think? DRMcCreedy (talk) 15:30, 31 August 2021 (UTC)[reply]
Hi, I would like to talk regarding your undo here.
I am new to contributing and I am trying to understand what is the difference between this source referenced as 32 in Letter frequency page and my reference to this blog. Both references are doing the exact same thing when the first one can get multiple references and the second one was rejected. I don't think there was a scientific claim there. They just took a well-known text and counted letter frequency. Is that make a difference if that counting is done in a blog published in practicalcryptography.com or in a blog published in armenianchat.net?
Thanks Inaxmo (talk) 21:01, 5 January 2022 (UTC)[reply]
Thanks for reaching out. The armenianchat.net source clearly falls under "Questionable sources" per Wikipedia guidelines as a group blog. Maybe practicalcryptography.com is also questionable as it could be a personal website but that's a little less obvious, at least to me. The other reason your edit caught my attention was the reference placement in what you added:
The phonetic layout is not very performant due to the letter frequency difference between the Armenian and English languages, although it is easier to learn and use.<ref>
. The reference supports frequency differences but was placed after "easier to learn and use". If you find an acceptable reference to re-add this, I'd suggest placing the reference after the comma so it's clear it supports the assertion about letter frequency. Ideally, you would have a citation to support the "easier to learn and use", which would go after the comma. I hope this helps explain my thought process even though it doesn't lay out a blank-and-white criteria for references. DRMcCreedy (talk) 21:40, 5 January 2022 (UTC)[reply]
Arabic unicode
Hello. I have been wondering about the reason Wikipedians use Arabic Unicode characters of the Presentation Forms (U+FB5x-U+FEFx) rather than the regular ones (U+060x-U+089x). As an example, you used the presentation forms too in one of your edits.
The presentation forms are never needed and their glyphs are not always supported by all Arabic typefaces. I keep correcting them all the time.
Thanks.
--Mahmudmasri (talk) 13:27, 10 February 2022 (UTC)[reply]
That edit was mainly a copy from French and German wiki pages and I wasn't aware the original text was using presentation forms. I see no reason for presentation forms to be used and support your effort to correct them. DRMcCreedy (talk) 22:25, 10 February 2022 (UTC)[reply]
Problems of your edit note of Arabic Extended-C and Arabic Mathematical Alphabetic Symbols
"I don't think it's notable if there's more than one"
I look out Plane (Unicode), it have more Arabic SMP block, but yeah, even I was outsighted there's other the Arabic block in SMP, which is Rumi Numeral Symbols, a set of numeric symbols used in Fez, Morocco, and elsewhere in North Africa and the Iberian peninsula between the tenth and seventeenth centuries. You outsighted recently added Arabic Extended-C block, so there are three Arabic blocks in SMP now.
That make sense the sentence "The block and Arabic Extended-C are only Arabic block defined in Supplementary Multilingual Plane (SMP)." seems superfluous that I don't need to add again.
Also, the edit note in Ahom (Unicode block) "Not remarkable Ahom block was expanded. Tangut Supplement was also expanded in v14.0." is explicit wrong, Tangut Supplement was shortened by to fix the erroneous block end point, and Ahom block I affirmed the block was first block to been extended of very long time, I never seen any blocks has been expended until 14.0, so yeah, Ahom is the first block has been expended since 1.1. Weather Top Wizard (talk) 10:31, 16 September 2022 (UTC)[reply]
My apologies... You are correct. I saw the block change for Tangut Supplement but didn't notice it got smaller. While it's interesting that Ahom is the first block expanded since 1.1, I still don't know that it's notable. Unicode itself doesn't point this out at http://www.unicode.org/reports/tr44/#Unicode_14.0.0 but instead just states the change happened. If Unicode itself doesn't note "it's been a long time", I lean towards leaving it out. But if you want to add it back with the "citation needed" note I won't remove it again. DRMcCreedy (talk) 17:32, 16 September 2022 (UTC)[reply]
U+E001
✰
The SHADOWED UNICODE BARNSTAR for —once again— updating our Unicode meticulously, this time into version 15.0
"Also, cite report isn't accurate because Unicode Consortium isn't a government body." Eh? Since when was report production a government monopoly? A slip of the pen, I assume? --𝕁𝕄𝔽 (talk) 10:24, 14 October 2022 (UTC)[reply]
I shouldn't update Wikipedia after midnight... I'm not at my best then. Re-reading Template:Cite report I suppose Unicode itself could fall under "major semi-governmental instrumentalities" but I'm not sure every proposal would be seen that way. I guess the real question would be is Template:Cite report better than plain, old Template:Citation used for the thousands of Unicode document citations on hundreds of Wikipedia articles? DRMcCreedy (talk) 15:23, 14 October 2022 (UTC)[reply]
good grief, it never to me that such a strange restriction would be in the template. Many NGOs publish reports and I have cited them using cite report. Maybe I should have used {{cite document}}. Oh wait... --𝕁𝕄𝔽 (talk) 18:19, 14 October 2022 (UTC)[reply]
This is a political issue with some very passionate people wanting Unicode to change the name of the "Bengali" block to include "Assamese" or to re-encode all Assamese characters in a new "Assamese" block. Both of these are impossible for Unicode to do technically. The compromise included an FAQ and adding text to the Unicode PDF: In Assam, the preferred name of the script is Asamiya or Assamese. I take your edit on good faith, and not another attempt to bring up the Bengali/Assamese debate, but I still can't support adding language information into the block templates. For example, the Myanmar block would then need footnotes for over a dozen languages: Aiton, Eastern Pwo Karen, Geba Karen, Kayah, Khamti Shan, Mon, Pali, Phake, Rumai Palaung, S'gaw Karen, Sanskrit, Shan, and Western Pwo Karen. DRMcCreedy (talk) 20:21, 12 February 2023 (UTC)[reply]
Are you familiar with the concept of image maps that define clickable areas on images used on web pages? This is the feature that allows you, for example, to view an image of the United States on a web page, and when you hover over each individual U.S. state, you can click it and go to an article about just that one state. So, for example, the US image might have 50 predefined clickable areas roughly corresponding to the state boundaries. You probably see where I'm going with this: if the little boxes (some of them, at least), on the Unicode images you are designing cover a set of code points for which we already have an article (or might have one in the future), you can define an image map so that clicking your image in the right square jumps to the Devanagari article, or whatever. You don't have to be a web designer yourself to do this, there are teams that can help; one is at WP:GL/I, but there may be others. That would be a really nice addition to your images. Mathglot (talk) 02:17, 19 November 2023 (UTC)[reply]
I've heard of this but hadn't considered it in this case. My first thought is that the categories match the Unicode Standard table of contents well but don't always map nicely to Wikipedia articles. My second thought is that because these SVG are used across different wikis the links would have to vary based on the Wikipedia using the image. I'm not sure how to get around that unless each wiki has its own set of SVGs which defeats the purpose of having shared, multilingual SVGs. DRMcCreedy (talk) 04:31, 19 November 2023 (UTC)[reply]
Two thoughts: I'm not an expert on this, but the image map doesn't reside in the image, it is separate, so I believe other wikis could ignore the map or use it (or create a different one) as they chose. But don't quote me on that. Another thing that occurs to me, is that you don't need to create different images, just so the text in the legend (or in the image) can be rendered in French, Spanish, or whatever. If you create your image as SVG, then you only need to have that one image for all 300 Wikipedias; you can translate just the labels with a tool here, without touching the image itself, and then the right image label text will come up in the right language depending on which Wikipedia you are looking at. I've used the svg translate tool myself to create multiple versions of some svg's for different languages. Once you've created one of them, you can crank them out in multiple languages, pasting the labels into a webform each time. See for example, c:File:Chronologie constitutions françaises.svg, which now has nine languages (click the dropdown to see). Mathglot (talk) 05:40, 19 November 2023 (UTC)[reply]
I should've clarified that I added French codes to the list because I often see "fre" in ISO 639-3 contexts (from "French") used incorrectly instead of "fra" (from "Français"). For that reason, I think it's pertinent to keep it, but I wouldn't add other languages blindly. Iketsi (talk) 00:19, 6 January 2024 (UTC)[reply]
I noticed you revert my edit (on the Georgian block page) where I changed "Asomtavruli capitals, known as Mtavruli..." to "Mkhedruli capitals, known as Mtavruli". I think you misread the context? Asomtavruli letters are sometimes considered capital letters (as you mentioned in your explanation) but this passage suggests that Mtavruli letters are capitals of the Asomtavruli letters themselves. As far as I know, they're two different (both nonstandard) ways of capitalizing Georgian text. That is, unless I'm misreading the sentence. I just wanted to check before I considered changing anything. Maybe the sentence could be written more clearly? Spaceexplorerer ᐵ (talk)02:06, 16 May 2024 (UTC)[reply]
Unfortunately I'm away from my home so I can't review my reference material but I think the issue is that Asomtavruli literally means "capital letters" so while it's true that both are used for emphasis, it's more accurate to refer to Asomtavruli, not Mkhedruli, as capitals. But you pointed out the real issue and that is that the script is unicameral so the sentence needs to be written more clearly. It's probably best to scratch that sentence entirely or to note how the two are both used for emphasis and how. DRMcCreedy (talk) 14:22, 16 May 2024 (UTC)[reply]
Noto fonts and unichar
Just FYI, {{unichar}} no longer requires a text description as the canonical text is now picked up from Wikidata. So {{unichar|0031}}, {{unichar|0031|digit 1}} and {{unichar|0031|digit one}} and even {{unichar|0031|DRMcCreedy}} should all give the same result: U+00311DIGIT ONE, U+00311DIGIT ONE and U+00311DIGIT ONE (and even U+00311DIGIT ONE). QED. 𝕁𝕄𝔽 (talk) 09:40, 15 July 2024 (UTC)[reply]
Thanks @JMF: for clarifying this. I knew that it was programmatically populated if omitted but didn't realize it was ignored entirely. The name is specified for the unichar template in around 600 articles. Is there any benefit in eventually removing it or should it be left to be treated as a comment? I'm guessing other editors are also confused by this, especially if they just copy from existing unichar examples. DRMcCreedy (talk) 17:16, 15 July 2024 (UTC)[reply]
Yes, we discussed that issue at template talk:unichar at the time the change was being made (as a result of some insidious vandalism and too many simple errors, plus the few cases of the Consortium correcting errors in their "we never touched nuffink, Guv, honest oh look a squirell" way . The consensus was that only the canonical name should ever be shown.) It think the conclusion was that it would be a huge amount of gnomic work for no evident return. So I (at least) have taken opportunities as presented, to simplify the calls when I'm doing a substantive edit. Over time, it will fade away. I hope that if someone hammers away trying to get 1 digit 1 but "the system" insists on returning 1 digit one, that they will go and read the template doc. Meanwhile, it does no harm as a sanity check and corrects editor typos for free. --𝕁𝕄𝔽 (talk) 20:00, 15 July 2024 (UTC)[reply]
Greetings and felicitations. I noticed that you reverted my edit to ISO 3166-2:GB. I made that edit because it was nearly impossible to find the Outer Hebrides' code, and Welsh locations already have alternate names in square brackets. (I only found the code in the Outer Hebrides article, having missed it previously.) Is there any proper way to add the same information that I did? —DocWatson42 (talk) 05:36, 26 October 2024 (UTC)[reply]
The alternate names in square brackets in the GB article are actually part of the Standard. For example https://www.iso.org/obp/ui/#iso:code:3166:GB lists GB-CAY as "Caerphilly [Caerffili GB-CAF]". That isn't the case for GB-ELS. A note about it being Outer Hebrides would be useful. Either add it to the text of the article or add a "[note 1]" after "Eilean Siar" with the text of the note after the table, similar to how ISO 3166-2:AM does (but instead of on a column, just after "Eilean Siar"). Cheers.DRMcCreedy (talk)
.svg){kind=icon}
![[4]](https://upload.wikimedia.org/wikipedia/commons/archive/8/8e/20080326232733%21Roadmap_to_Unicode_BMP.svg){kind=link}
