User talk:HarJIT/Archives/ 1

Welcome!
Hello, Thomas.hori, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few links to pages you might find helpful: Please remember to sign your messages on talk pages by typing four tildes ( ~ ); this will automatically insert your username and the date. If you need help, check out Questions, ask me on my talk page, or ask your question on this page and then place  before the question. Again, welcome!
 * Getting Started
 * Introduction to Wikipedia
 * The five pillars of Wikipedia
 * How to edit a page and How to develop articles
 * How to create your first article
 * Simplified Manual of Style

January 2014
Hello, I'm BracketBot. I have automatically detected that [//en.wikipedia.org/w/index.php?diff=591263511 your edit] to Nyan Cat may have broken the syntax by modifying 1 "[]"s. If you have, don't worry: just [ edit the page] again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on [//en.wikipedia.org/w/index.php?action=edit&preload=User:A930913/BBpreload&editintro=User:A930913/BBeditintro&minor=&title=User_talk:A930913&preloadtitle=BracketBot%20–%20&section=new my operator's talk page].
 * List of unpaired brackets remaining on the page:

Thanks, BracketBot (talk) 12:53, 18 January 2014 (UTC)
 * archive.org/web/20110531001830/http://nyan.cat/ The original nyan.cat, over the Wayback Machine and the same background music. The site, which uses the .cat [[sponsored top-level

Jeanneke Pis
You asked if there's any reason why a picture is not included. I have an answer: the statue and all photos of it are still under copyright under Belgian law, so any picture of it is reproducing copyrighted material, which is against Wikipedia policy. That being said, nobody else except Wikipedia seems to have a problem with this, but Wikipedia is a bit of a stickler for the rules. If you have any questions, let me know. Cheers,  Oreo Priest  talk 14:56, 20 February 2014 (UTC)

Disambiguation link notification for April 11
Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Joseph Smith Hypocephalus, you added a link pointing to the disambiguation page Sokar (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ* Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 08:58, 11 April 2014 (UTC)

ArbCom elections are now open!
Hi, You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 16:56, 24 November 2015 (UTC)

Disambiguation link notification for July 13
Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Daibutsu, you added a link pointing to the disambiguation page Giant Buddha. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ* Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:30, 13 July 2016 (UTC)

Disambiguation link notification for December 14
Hi. Thank you for your recent edits. An automated process has detected that when you recently edited JIS X 0208, you added a link pointing to the disambiguation page Code page 932 ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/JIS_X_0208 check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/JIS_X_0208?client=notify fix with Dab solver]). Such links are usually incorrect, since a disambiguation page is merely a list of unrelated topics with similar titles. (Read the FAQ* Join us at the DPL WikiProject.)

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 18:18, 14 December 2017 (UTC)

Disambiguation link notification for February 18
An automated process has detected that when you recently edited Code page 936 (IBM), you added a link pointing to the disambiguation page GBK ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Code_page_936_%28IBM%29 check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Code_page_936_%28IBM%29?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 09:57, 18 February 2018 (UTC)

Disambiguation link notification for February 25
An automated process has detected that when you recently edited Tamil All Character Encoding, you added a link pointing to the disambiguation page Private use area ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Tamil_All_Character_Encoding check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Tamil_All_Character_Encoding?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 09:09, 25 February 2018 (UTC)

Disambiguation link notification for March 12
An automated process has detected that when you recently edited Extended Unix Code, you added a link pointing to the disambiguation page Japanese ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Extended_Unix_Code check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Extended_Unix_Code?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 09:05, 12 March 2018 (UTC)

Disambiguation link notification for April 15
An automated process has detected that when you recently edited ISO-IR-153, you added a link pointing to the disambiguation page ECMA ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/ISO-IR-153 check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/ISO-IR-153?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 09:21, 15 April 2018 (UTC)

I removed the redirect for IBM 897
Because more information is in a separate article. Also, I'm redirecting IBM 1041 to this page instead. Feel free to undo if you and the people aren't satisfied. (Please state the reason). Alexlatham96 (talk) 00:30, 11 May 2018 (UTC)

Disambiguation link notification for August 16
An automated process has detected that when you recently edited Macintosh Ukrainian encoding, you added a link pointing to the disambiguation page Ukrainian ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Macintosh_Ukrainian_encoding check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Macintosh_Ukrainian_encoding?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 09:18, 16 August 2018 (UTC)

Stop removing large portions of contents
Please stop removing large portions of contents as you did in the Xerox Character Code Standard article. We are Wikipedia and don't depend on projects like Wiktionary. I'm not sure what you were after, but in either case, please discuss such bold intended changes before on the article talk pages and don't carry them out unless there is consensus for them. --Matthiaspaul (talk) 09:24, 4 September 2018 (UTC)
 * I see that you are also carrying out mass changes to other character set tables and the corresponding template framework. Please stop this immediately, there is no consensus for these changes. --Matthiaspaul (talk) 09:30, 4 September 2018 (UTC)
 * As most of your edits don't have an edit summary could you please explain what you were after? --Matthiaspaul (talk) 09:44, 4 September 2018 (UTC)


 * User:Spitzak was apparently trying to boldly redo the formatting and change the colouration to match Unicode character categories. i.e. L/P/S/M/Z/C (and had been editing the templates, reducing the number of colours etc accordingly). I couldn't come up with any point to counter this with (after all, Unicode character categories are, for all their flaws, an objective non-OR system), so I was trying to make things consistently use that scheme.
 * While I was editing the template framework, that was mostly with the intention of trying to tidy it up after Spitzak. While I did add the kuten stuff, that had been included in most of the tables it was applicable to for some time already, outside the template call; I thought it would be tidier to support it in the templates themselves.
 * As for XCCS, including a couple of kanji tables but not all of them feels slightly misleading (at best suggesting the rest of the mapping not to be known, and at worst suggesting that to be the encoding's entire kanji support), and whilst I could comparatively easily generate the full set and include them, that would increase the article length to many times what it is currently. Hence I was linking to where the full information was already available.
 * Whilst it didn't have a lead byte table until I recently added it, JIS X 0208 had been pointing to Wiktionary for that purpose for almost 9 months now, KS X 1001 had been doing so for no short space of time and KPS 9566 had been doing so ever since its tables were added, and you're the first person to complain, so I (I thought) reasonably assumed people were happy with that. -- HarJIT (talk) 11:12, 4 September 2018 (UTC)
 * Hi HarJIT, thanks for your reply.
 * Can you point me to where Spitzak is boldly trying to redo the formatting, because Spitzak has been advised (by me) not to do it without community consensus.
 * While the existing tables are not perfect, I would rather add more information (codes, colors, attributes) to them whereas Spitzak apparently wants sleak small tables with only the glyphs being shown for mobile devices - which would make it impossible to derive character mapping information and exceptions from the tables and therefore would render them meaningless for "serious" work.
 * What exactly do you mean by "colouration to match Unicode character categories"? Given that most oode pages and character sets long pre-date the advent of Unicode, I'm not sure if applying Unicode categories to them makes sense. Our current system appears to be loosely based on ASCII character categorization, but with some extensions.
 * --Matthiaspaul (talk) 18:53, 4 September 2018 (UTC)

Disambiguation link notification for November 8
An automated process has detected that you recently added links to disambiguation pages.
 * Baudot code ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Baudot_code check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Baudot_code?client=notify fix with Dab solver])
 * added a link pointing to Line break

(Opt-out instructions.) --DPL bot (talk) 18:22, 8 November 2018 (UTC)

Disambiguation link notification for February 13
An automated process has detected that when you recently edited ARIB STD B24 character set, you added a link pointing to the disambiguation page Station ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/ARIB_STD_B24_character_set check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/ARIB_STD_B24_character_set?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 11:40, 13 February 2019 (UTC)

A page you started (Code page 5471) has been reviewed!
Thanks for creating Code page 5471.

I have just reviewed the page, as a part of our page curation process and note that:

To reply, leave a comment here and prepend it with. And, don't forget to sign your reply with.

Message delivered via the Page Curation tool, on behalf of the reviewer.

signed,Rosguill talk 19:41, 6 May 2019 (UTC)

Thank you. I have added the appropriate mention and citation. --HarJIT (talk) 19:49, 6 May 2019 (UTC)

Null edit needed
Please can you null edit User:HarJIT/userpage.css. It is populating Category:Potentially illegible userboxes and creating errors for the redirect bot. Thanks in advance. Timrollpickering (Talk) 10:40, 9 July 2019 (UTC)

Done. -- HarJIT (talk) 13:11, 9 July 2019 (UTC)

Character set coloration
I see you are trying to avoid the "box problem" by coloring the character sets. I did look at this before. My idea was to get rid of the rather pointless coloring for character types (except for gray for unassigned) so that colors can be used for this more interesting information. What do you think of this?

My first proposal was the following, which put all the Unicode info into the tooltip and otherwise made the table more attractive IMHO:

{{legend|#DDD|Not in first version}} {{legend|#ABC|Not in second version}} {{legend|#A00|Another legend}}

This was rejected by user User:Matthiaspaul who complained that it "violated long standing consensus" though I was unable to find anybody other than him that was a member of this consensus.

Despite this, I have managed to get rid of the decimal numbers, and to change the color of letters to white, and get footnotes next to the glyphs. But I would like to continue, possibly by eliminating the colors entirely and changing all the boxes and -var to colors. What do you think?

If you don't like the idea, perhaps making the checkerboard you put in much more visible would help. Spitzak (talk) 17:48, 13 August 2019 (UTC)

Also you can see in the table above that making an entry into a link interferes with the display of the tooltip, do you know if there is a way to get around this?


 * Thank you for your comments.
 * Storing information in tooltips can sometimes be problematic due to sometimes being difficult to view, at least in their entirety, with mobile devices (the main reason why https://m.xkcd.com/ exists, despite https://xkcd.com/ being otherwise fairly mobile-friendly). The inclusion of the names of the mapped character is a nice touch, although I'd be wary of simply making it akin to the Unicode block tables, since they have slightly different purposes: the Unicode codepoints in the Unicode charts are visible from their position, whereas one of the purposes of the non-Unicode tables is to visualise the Unicode mappings.
 * As for your changes to the table formatting a while back: on the whole, I thought they were positive, despite some inconsistencies left that I had to clean up (hence making chset-cell-unified to try to stop them getting out of sync again). The previous colour system was confusing:
 * What exactly "international" was supposed to be used for was never well documented.
 * Although what constituted "extended" punctuation was documented, it wasn't used consistently in practice.
 * Where "punctuation" ended and "graphical" began was highly subjective.
 * A few articles just went off and did their own thing, e.g. certain EBCDIC pages only colouring unchanged characters, and using white background to show changed ones.
 * Too many colours can make them hard to tell apart.
 * I felt using Unicode categories where possible was a genuine improvement, largely due to these complications, and due to allowing the categories to be mechanically corrected (subject, of course, to manual checking). I did spend the best part of a Saturday going through articles and updating them to the new format (especially considering that the templates had already been changed), also meaning standardising the format for those which weren't exactly following it already. Although Matthias Paul made it clear to me soon after I'd finished that he was not happy about me having done this unilaterally.
 * There is definitely room to make the checkerboard pattern darker; I was erring on the side of not being too dark, since I was concerned about interfering with legibility.
 * In any case, it's worth noting that the colour categories we are currently using are not created equal:
 * Undefined cells are not characters.
 * Graphical spacing characters (i.e. all four of letters, digits, punctuation and symbols) are simply what you see in the chart (assuming correct font support).
 * Control, format or separator characters are non-printing and shown using mnemonics, i.e. are not what you see.
 * Combining characters (in e.g. Windows-1258, VSCII, VISCII, ANSEL) are currently shown the same colour as whitespace and control characters, but have their own unique considerations, insofar as they modify other characters rather than just showing up as shown, and in some cases legacy encodings use a different ordering than Unicode (ANSEL prefixes, Unicode affixes). Although you can tell the difference in that they aren't mnemonics, so the same colourisation does work for now.
 * Lead bytes are not characters (and nor are UTF-8 and UTF-EBCDIC continuation bytes, although the UTF-8 article uses its own colour key due to its distinctive requirements, something worth bearing in mind).
 * Private use mappings for non-Unicode characters should probably be shown using images or other simulations where this is appropriate (might not be for trademark logos?). For instance, that's what I'm trying to do for KPS 9566. Although if private use mappings are widely used for those characters where that encoding is used (the ones shown there are documented by Unicode's mapping collection and indeed used e.g. by the KP series fonts from Red Star OS), they are likely to be worth showing the codepoints.
 * Private use mappings for end-user defined characters are not usually worth showing the characters for, given that they'll look different to everyone, but showing the codepoint might be useful to show in terms of seeing which EUDC representations in different encodings correspond / potentially collide. Not that we really have many of these charted (many are better documented as formulas, after all).
 * So there is definitely room for future improvement… (although it might upset fewer people to create a new colour template system and slowly migrate to it rather than just changing the existing one).
 * Although as a postscript while we're discussing this, a note on kuten codes: it's a distinctive consideration when documenting JIS X 0208, KS C 5601, GB 2312, KPS 9566 and a few others, which are actually defined on a 94-by-94 grid of characters and usually referenced by their positions on that 94-by-94 grid (for instance, elsewhere in the article, or in the kanji index), even though these are actually stored as pairs of bytes (either from 0x21 to 0x7E for 7-bit form, or from 0xA1 to 0xFE for EUC form). It also means that the grid squares for 0xA0 and 0xFF aren't strictly part of the chart (indeed, some EUC extensions such as Unified Hangul Code or GBK might use the 0xA0 trail bytes for something else, which has nothing to do with the 94-by-94 code itself). (Although some observations, such as the ISO 646 nature of row 3 of all four of the mentioned, are most easily spotted with a trail byte chart as presently used.)
 * -- HarJIT (talk) 19:08, 13 August 2019 (UTC)
 * Private use mappings for non-Unicode characters should probably be shown using images or other simulations where this is appropriate (might not be for trademark logos?). For instance, that's what I'm trying to do for KPS 9566. Although if private use mappings are widely used for those characters where that encoding is used (the ones shown there are documented by Unicode's mapping collection and indeed used e.g. by the KP series fonts from Red Star OS), they are likely to be worth showing the codepoints.
 * Private use mappings for end-user defined characters are not usually worth showing the characters for, given that they'll look different to everyone, but showing the codepoint might be useful to show in terms of seeing which EUDC representations in different encodings correspond / potentially collide. Not that we really have many of these charted (many are better documented as formulas, after all).
 * So there is definitely room for future improvement… (although it might upset fewer people to create a new colour template system and slowly migrate to it rather than just changing the existing one).
 * Although as a postscript while we're discussing this, a note on kuten codes: it's a distinctive consideration when documenting JIS X 0208, KS C 5601, GB 2312, KPS 9566 and a few others, which are actually defined on a 94-by-94 grid of characters and usually referenced by their positions on that 94-by-94 grid (for instance, elsewhere in the article, or in the kanji index), even though these are actually stored as pairs of bytes (either from 0x21 to 0x7E for 7-bit form, or from 0xA1 to 0xFE for EUC form). It also means that the grid squares for 0xA0 and 0xFF aren't strictly part of the chart (indeed, some EUC extensions such as Unified Hangul Code or GBK might use the 0xA0 trail bytes for something else, which has nothing to do with the 94-by-94 code itself). (Although some observations, such as the ISO 646 nature of row 3 of all four of the mentioned, are most easily spotted with a trail byte chart as presently used.)
 * -- HarJIT (talk) 19:08, 13 August 2019 (UTC)
 * Although as a postscript while we're discussing this, a note on kuten codes: it's a distinctive consideration when documenting JIS X 0208, KS C 5601, GB 2312, KPS 9566 and a few others, which are actually defined on a 94-by-94 grid of characters and usually referenced by their positions on that 94-by-94 grid (for instance, elsewhere in the article, or in the kanji index), even though these are actually stored as pairs of bytes (either from 0x21 to 0x7E for 7-bit form, or from 0xA1 to 0xFE for EUC form). It also means that the grid squares for 0xA0 and 0xFF aren't strictly part of the chart (indeed, some EUC extensions such as Unified Hangul Code or GBK might use the 0xA0 trail bytes for something else, which has nothing to do with the 94-by-94 code itself). (Although some observations, such as the ISO 646 nature of row 3 of all four of the mentioned, are most easily spotted with a trail byte chart as presently used.)
 * -- HarJIT (talk) 19:08, 13 August 2019 (UTC)
 * -- HarJIT (talk) 19:08, 13 August 2019 (UTC)

Google Code-In 2019 is coming - please mentor some documentation tasks!
Hello,

Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at the English Wikipedia.

I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!

From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.

If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.

Thank you!

--User:Martin Urbanec (talk) 21:58, 23 November 2019 (UTC)

Nomination for deletion of Template:Main Page alternative (HS) welcome notice
Template:Main Page alternative (HS) welcome notice has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. * Pppery * it has begun... 03:39, 17 February 2020 (UTC)

Disambiguation link notification for March 14
Hi. Thank you for your recent edits. An automated process has detected that when you recently edited KS X 1001, you added a link pointing to the disambiguation page GBK ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/KS_X_1001 check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/KS_X_1001?client=notify fix with Dab solver]). Such links are usually incorrect, since a disambiguation page is merely a list of unrelated topics with similar titles. (Read the FAQ* Join us at the DPL WikiProject.)

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 13:35, 14 March 2020 (UTC)

DYK nomination of KPS 9566
Hello! Your submission of KPS 9566 at the Did You Know nominations page has been reviewed, and some issues with it may need to be clarified. Please review the comment(s) at your nomination's entry and respond there as soon as possible. Thank you for contributing to Did You Know! Yoninah (talk) 23:22, 13 June 2020 (UTC)

DYK for KPS 9566
—valereee (talk) 00:02, 20 June 2020 (UTC)

Disambiguation link notification for July 12
An automated process has detected that when you recently edited Emoji, you added a link pointing to the disambiguation page PNG ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Emoji check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Emoji?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 06:15, 12 July 2020 (UTC)

Disambiguation link notification for July 19
An automated process has detected that when you recently edited Chinese Character Code for Information Interchange, you added a link pointing to the disambiguation page ↑ ([//dispenser.info.tm/~dispenser/cgi-bin/dablinks.py/Chinese_Character_Code_for_Information_Interchange check to confirm] | [//dispenser.info.tm/~dispenser/cgi-bin/dab_solver.py/Chinese_Character_Code_for_Information_Interchange?client=notify fix with Dab solver]).

(Opt-out instructions.) --DPL bot (talk) 06:24, 19 July 2020 (UTC)

Disambiguation link notification for July 26
An automated process has detected that you recently added links to disambiguation pages.
 * Chinese Character Code for Information Interchange
 * added links pointing to ↓, ≡, ← and →

(Opt-out instructions.) --DPL bot (talk) 06:10, 26 July 2020 (UTC)

Disambiguation link notification for August 2
An automated process has detected that when you recently edited Chinese Character Code for Information Interchange, you added a link pointing to the disambiguation page 丁.

(Opt-out instructions.) --DPL bot (talk) 06:42, 2 August 2020 (UTC)

Template Charmap
Hey, I've been noticing you doing some maintenance on. Given that GB 18030 encodes the full UCS code point range algorithmically, I would suggest making an analogue to for the GB 18030 mappings for implementation into Charmap, like we did with UTF-8. I feel like you've probably delved too deep into trying to change things around instead of just adding on to the basic functioning of just inputting another table row into /head. Most importantly you are hardcoding into this template the GB 18030 mapping, which is useful outside this template as well. VanIsaacWScont 00:14, 18 August 2020 (UTC)


 * Okay. I've now moved the GB18030 encoding stuff to, where it can be used elsewhere with much the same invocation as . --HarJIT (talk)
 * Oh, that looks really good. I see that you updated the Unicode templates navbox as well. I've updated the example in template:charmap to show "IncludeGB=yes". I'm also going to put a notice at WT:WikiProject Writing systems to see whether people think it should be set to "yes" by default. VanIsaacWScont 07:25, 19 August 2020 (UTC)

Disambiguation link notification for September 27
An automated process has detected that when you recently edited ISO-IR-165, you added a link pointing to the disambiguation page Code page 936.

(Opt-out instructions.) --DPL bot (talk) 10:22, 27 September 2020 (UTC)

Disambiguation link notification for March 8
An automated process has detected that you recently added links to disambiguation pages.
 * C0 and C1 control codes
 * added a link pointing to IEC
 * Unicode control characters
 * added a link pointing to IEC

(Opt-out instructions.) --DPL bot (talk) 06:18, 8 March 2021 (UTC)

Disambiguation link notification for April 14
An automated process has detected that when you recently edited Radical 213, you added a link pointing to the disambiguation page GBK.

(Opt-out instructions.) --DPL bot (talk) 06:08, 14 April 2021 (UTC)

Nomination for deletion of Template:Charmap/showchar
Template:Charmap/showchar has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 16:17, 26 April 2021 (UTC)

North London Railway diagram
This template was created by a user that I later blocked basically for being totally incompetent (and then later found they had created a dozen or so other accounts as well). So, this whole thing is somewhat suspect. They seem to be quite the "rail fan" but I wouldn't trust anything they created unless it can be conclusively verified by a source. It might be wise to just take it out of use until it has been verified, or an alternate version is created by someone more competent to do so. Beeblebrox (talk) 21:13, 20 May 2021 (UTC)

North London Railway diagram
This template was created by a user that I later blocked basically for being totally incompetent (and then later found they had created a dozen or so other accounts as well). So, this whole thing is somewhat suspect. They seem to be quite the "rail fan" but I wouldn't trust anything they created unless it can be conclusively verified by a source. It might be wise to just take it out of use until it has been verified, or an alternate version is created by someone more competent to do so. Beeblebrox (talk) 21:13, 20 May 2021 (UTC)

Ginza Rba
Thanks for adding Al-Saadi's chapter numbers to Ginza Rba. I've just added the chapters for Book 15, which don't have Al-Saadi's chapter numbers yet.

I don't have access to the Carlos Gelbert and Qais Al-Saadi translations. Do you know how I can have access? Nebulousquasar (talk) 15:43, 4 September 2021 (UTC)


 * For Al-Saadi, I had to import the physical book from Germany over Amazon. I don't have Gelbert's, so I couldn't comment. -- HarJIT (talk) 09:19, 5 September 2021 (UTC)


 * The parts of the Right Ginza that don't seem (from what I can tell) to correspond to Lidzbarski's chapter numbering are Al-Saadi's 18.1 and 19. Collectively, they're only three pages (sides) out of the entire book, so I thought I may as well take photos (18.1 and 19; not putting them on Commons though for obvious reasons).
 * I haven't looked into the Left Ginza yet, although I do note that Al-Saadi writes in the translation preface I was of the opinion not to include refined texts which reflect the same meaning or have an identical content, especially in the left part. But I included one more tractate in Book Three of the "left" part; this section was not translated into Arabic, and refers to Sunday and its importance as a sacred day.
 * so there are probably some differences in chapter/hymn numbering and inclusion there also. --HarJIT (talk) 15:57, 5 September 2021 (UTC)
 * Thanks HarJIT, this is very helpful. I have ordered physical copies of both the Drabsha (Al-Saadi) and Living Water (Gelbert) versions and am waiting for them to arrive. Both are copyrighted, so I think it would be a good idea for us Wikimedians to publish our own new open-source English translation of Lidzbarski's Ginza Rba on Wikisource. We could try starting wikisource:Translation:Ginza Rba. wikisource:Translation:Book of John the Baptist, a translation of Book 7 of the Right Ginza, already exists. Since Mark Lidzbarski's translation was published in 1925 and it has been 93 years since his death in 1928, it is public domain and can be fully digitized at Ginza Rba.
 * This is of course a monumental task, and I only have time to do little bits and pieces. Nebulousquasar (talk) 16:52, 5 September 2021 (UTC)
 * Some updates: I've copied the scan of Lidzbarski's translation to Commons and had created a transcription index for it, but was subsequently informed that German Wikisource apparently has rules which must be met before a large transcription project may be undertaken. Hmm… --HarJIT (talk) 15:58, 6 September 2021 (UTC)
 * That's a lot of rules! I think we may be better off starting off with an English translation for the English Wikisource, which does not have quite as many rules. Nebulousquasar (talk) 22:05, 11 September 2021 (UTC)
 * Carlos Gelbert's version is an English translation of Lidzbarski (1925). Consulting this could be helpful, although we must make sure to not directly copy anything off this copyrighted translation. Nebulousquasar (talk) 22:08, 11 September 2021 (UTC)

Disambiguation link notification for September 30
An automated process has detected that when you recently edited Emoji, you added a link pointing to the disambiguation page Ligature.

(Opt-out instructions.) --DPL bot (talk) 05:59, 30 September 2021 (UTC)

Disambiguation link notification for October 13
An automated process has detected that when you recently edited Code page 949 (IBM), you added a link pointing to the disambiguation page 甌.

(Opt-out instructions.) --DPL bot (talk) 05:56, 13 October 2021 (UTC)

Merry Christmas


2001:4455:1A9:E100:CCE2:2E85:49C3:C360 (talk) is wishing you a Merry Christmas! This greeting (and season) promotes WikiLove and hopefully this note has made your day a little better. Spread the WikiLove by wishing another user a Merry Christmas, whether it be someone you have had disagreements with in the past, a good friend, or just some random person. Don't eat yellow snow!

Spread the holiday cheer by adding to their talk page with a friendly message. --2001:4455:1A9:E100:CCE2:2E85:49C3:C360 (talk) 07:40, 27 December 2021 (UTC)

August 2022
Hello. I have noticed that you edit without using an edit summary. Please do your best to always fill in the summary field. This helps your fellow editors use their time more productively, rather than spending it unnecessarily scrutinizing and verifying your work. Even a short summary is better than no summary, and summaries are particularly important for large, complex, or potentially controversial edits. To help yourself remember, you may wish to check the "prompt me when entering a blank edit summary" box in your preferences. Thanks! Joyce-stick (talk) 23:41, 26 August 2022 (UTC)


 * Out of curiosity, what template is this (I'm assuming it's a subst:'d template, since it certainly reads like one, apologies if I'm wrong)?
 * I suppose this is where my occupation (both recreationally and professionally) in computer programming / software development shows through. You might notice that when I fill in an edit summary, it's most often to give insight not trivially discernable from the diff itself—especially if, as you say, it is potentially controversial (or would otherwise constitute WP:UCR)—reflecting the programming practice that source code comments should not laboriously restate anything that is obvious from reading the source code itself, but should be used for insight that isn't otherwise obvious.
 * I presume this is in response to my cleaning up of the Blåhaj chronology, which can be viewed as a single combined diff using the radio-button feature, at least on the desktop site (or alternatively, an overall diff to the revision could be viewed with a "cur" link). For the most part, the individual edits struck me as fairly self-explanatory, as does the overall diff.
 * For pages I'm watching, I tend to unconditionally check the overall diffs when they change, since edit summaries can be unreliable (from vandals or test edits) or inspecific (otherwise) and, furthermore, generally don't reveal mistakes that an editor might have made without realising. Would you be able to elaborate on how more edit summaries would have reduced time "unnecessarily scrutinizing and verifying" by others? --HarJIT (talk) 11:20, 27 August 2022 (UTC)
 * I presume this is in response to my cleaning up of the Blåhaj chronology, which can be viewed as a single combined diff using the radio-button feature, at least on the desktop site (or alternatively, an overall diff to the revision could be viewed with a "cur" link). For the most part, the individual edits struck me as fairly self-explanatory, as does the overall diff.
 * For pages I'm watching, I tend to unconditionally check the overall diffs when they change, since edit summaries can be unreliable (from vandals or test edits) or inspecific (otherwise) and, furthermore, generally don't reveal mistakes that an editor might have made without realising. Would you be able to elaborate on how more edit summaries would have reduced time "unnecessarily scrutinizing and verifying" by others? --HarJIT (talk) 11:20, 27 August 2022 (UTC)
 * For pages I'm watching, I tend to unconditionally check the overall diffs when they change, since edit summaries can be unreliable (from vandals or test edits) or inspecific (otherwise) and, furthermore, generally don't reveal mistakes that an editor might have made without realising. Would you be able to elaborate on how more edit summaries would have reduced time "unnecessarily scrutinizing and verifying" by others? --HarJIT (talk) 11:20, 27 August 2022 (UTC)


 * It makes it easier to look at the edit history and see at a glance what you did, without needing to parse out the differences ourselves (which can sometimes be confusingly rendered in the diff viewer). As for the template, I don't remember the exact name, I placed it with Twinkle so I didn't really think about it too much. It's ultimately not a big deal that you didn't summarize it since the edits were clearly constructive, it just makes things a tiny bit more convenient for some others and that can go a long way. Ultimately though this isn't something I'd think is worth arguing over or insisting on, in this case, especially if I seem to be the only one who's at all taken any issue. I greatly appreciate your help cleaning up the page regardless. Joyce-stick (talk) 11:44, 27 August 2022 (UTC)

ArbCom 2022 Elections voter message
 Hello! Voting in the 2022 Arbitration Committee elections is now open until 23:59 (UTC) on. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2022 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add to your user talk page. MediaWiki message delivery (talk) 01:09, 29 November 2022 (UTC)

CS1 error on Make (software)
Hello, I'm Qwerfjkl (bot). I have automatically detected that this edit performed by you, on the page Make (software), may have introduced referencing errors. They are as follows: Please check this page and fix the errors highlighted. If you think this is a false positive, you can [//en.wikipedia.org/w/index.php?action=edit&preload=User:Qwerfjkl/Botpreload&editintro=User:Qwerfjkl/boteditintro&minor=&title=User_talk:Qwerfjkl&preloadtitle=Qwerfjkl%20(bot)%20–%20Qwerfjkl_(bot)&section=new report it to my operator]. Thanks, Qwerfjkl (bot) (talk) 16:05, 22 May 2023 (UTC)
 * A "bare URL and missing title" error. References show this error when they do not have a title. Please edit the article to add the appropriate title parameter to the reference. ([//en.wikipedia.org/w/index.php?title=Make_(software)&action=edit&minor=minor&summary=Fixing+reference+error+raised+by+%5B%5BUser%3AQwerfjkl%20(bot)%7CQwerfjkl%20(bot)%5D%5D Fix] | [//en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&action=edit&section=new&preload=User:Qwerfjkl%20(bot)/helpform&preloadtitle=Referencing%20errors%20on%20%5B%5BSpecial%3ADiff%2F1156384178%7CMake%20(software)%5D%5D Ask for help])

ArbCom 2023 Elections voter message
 Hello! Voting in the 2023 Arbitration Committee elections is now open until 23:59 (UTC) on. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2023 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add to your user talk page. MediaWiki message delivery (talk) 00:41, 28 November 2023 (UTC)

Etymology of ANSI escape sequence type designators?
Hi, I think it was you who originally added information on ANSI escape sequence categorisation to the ANSI escape code article. You noted that applicable standards distinguish types Fe, Fs, Fp and nF.

What I can't seem to figure out is if there is any information anywhere on exactly what those designators stand for? The standards documents don't seem to clearly define that. Is the F always for Final? If yes, then I might guess that perhaps Fp is for Final, private-use, and nF for numbered Final, but I can't seem to find any source that actually says that, and I'm really not sure what Fe and Fs actually stand for.

Do you know, or do you know where one might be able to find out?

(Also, do you think it would be better to have this conversation on Talk:ANSI escape code? Feel free to copy/move this there if you do.) —ReadOnlyAccount (talk) 03:52, 19 December 2023 (UTC)


 * The standard in question is ECMA-35 (ISO 2022), since it defines the general format for escape sequences in general (while ECMA-48 just defines a C1 control (and thus Fe) escape sequence) set, and a few Fs escape sequences). The relevant chapter of ECMA-35 is chapter 13.2.


 * Yes, F would appear to be for "final" (nF has the "type indicator" before the "Final Byte"; the others have the final byte as their type indicator). Fs is defined as "Standardized single control function" so the s probably stands for "single". How the abbreviation …Ft (as a nF subtype) represents "Standardised purposes" or the abbreviation Fe represents "Control function in the C1 set" isn't made clear. The n in nF does stand in for a number, basically as a placeholder to refer to 0F, 3F etc escape sequences as a collective, i.e. those that have a type indicator besides the final byte:


 * The type "nF" in the above table indicates escape sequences of the series of types whose names are of the form

nF where n may take any value from 0 to 15, as listed in table 3.b.


 * --HarJIT (talk) 15:26, 19 December 2023 (UTC)


 * Thanks for replying. If I understand correctly, then the best we can establish is the following:
 * Fe is for Final "e", but it's unknown what the e represents,
 * Fs is for Final, single (probably), ✓
 * Fp is for Final, private-use (probably), ✓
 * nF is for [numbered] Final, and ✓
 * Ft has an unknown etymology.


 * I find that lack of a information what these codes actually stand for quite frustrating, and I think that impedes understanding. Also, none of the above is really spelled-out well enough for cited inclusion in the article. Worse, this is an old standard, and it looks like the meaning of all of this has never really been made clear. Perhaps the Byzantine nature of the scheme and nomenclature played a role it its adoption and success ultimately having been quite limited. I only ended up at ISO 2022 because I wanted to find out more about where GB 18030 came from – speaking of which, if you know anything about the latter, please let me know.
 * As for this present somewhat annoyingly unresolved mystery, do you think the Helpdesk@ email address mentioned on the cover page of your above ECMA-35 PDF still works? I'm not sure if this is worth asking people about, and I'm even less confident about the odds of our receiving a meaningful answer. –ReadOnlyAccount (talk) 05:55, 21 December 2023 (UTC)

Keycap sequences in Unicode
Yes, that was better. I see that the same Unicode Consortium document has similar sequences for asterisk and 0 – 9. Perhaps you might add those to their respective articles? 𝕁𝕄𝔽 (talk) 11:20, 24 January 2024 (UTC)