Hello Spitzak, and welcome to Wikipedia!
(If you find this note to be too bulky, feel free to remove it whenever you want)

Thank you for your contributions, we are pleased to have you here and I hope you stay. I recommend you have a quick look through the Five Pillars of Wikipedia - this page gives a brief summary of what we value here, and if you want some tutorial on how to edit have a glance at Wikipedia:Welcome. Below is a collection of some other pages that you may find helpful, feel free to read them at your leasure if and when you want. (But of course you don't have to read any of that to contribute!)

If you need help with anything, please feel free to contact me on my talk page. Or altertnatively type {{helpme}} here and a user will help you as soon as possible. But remember to sign all your posts on talk/discussion pages with ~~~~, this helps us track of who's saying what and when in discussions.

Once again Welcome to Wikipedia, and happy editing!

Konst.able 19:45, 17 October 2006 (UTC)
Getting started
Getting your info out there
Getting more Wikipedia rules
Getting help
Getting along
Getting technical
Wikimedia.png

Image without licenseEdit

Unspecified source/license for Image:Utf8diagram.pngEdit

Thanks for uploading Image:Utf8diagram.png. The image has been identified as not specifying the copyright status of the image, which is required by Wikipedia's policy on images. Even if you created the image yourself, you still need to release it so Wikipedia can use it. If you don't indicate the copyright status of the image on the image's description page, using an appropriate copyright tag, it may be deleted some time in the next seven days. If you made this image yourself, you can use copyright tags like {{PD-self}} (to release all rights), {{self|CC-by-sa-3.0|GFDL}} (to require that you be credited), or any tag here - just go to the image, click edit, and add one of those. If you have uploaded other images, please verify that you have provided copyright information for them as well.

For more information on using images, see the following pages:

This is an automated notice by MifterBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. NOTE: once you correct this, please remove the tag from the image's page. --MifterBot (TalkContribsOwner) 00:29, 5 September 2008 (UTC)

File permission problem with File:Nuke screenshot.pngEdit

Thanks for uploading File:Nuke screenshot.png. I noticed that while you provided a valid copyright licensing tag, there is no proof that the creator of the file agreed to license it under the given license.

If you created this media entirely yourself but have previously published it elsewhere (especially online), please either

  • make a note permitting reuse under the CC-BY-SA or another acceptable free license (see this list) at the site of the original publication; or
  • Send an email from an address associated with the original publication to permissions-en@wikimedia.org, stating your ownership of the material and your intention to publish it under a free license. You can find a sample permission letter here.

If you did not create it entirely yourself, please ask the person who created the file to take one of the two steps listed above, or if the owner of the file has already given their permission to you via email, please forward that email to permissions-en@wikimedia.org.

If you believe the media meets the criteria at Wikipedia:Non-free content, use a tag such as {{non-free fair use in|article name}} or one of the other tags listed at Wikipedia:Image copyright tags#Fair use, and add a rationale justifying the file's use on the article or articles where it is included. See Wikipedia:Image copyright tags for the full list of copyright tags that you can use.

If you have uploaded other files, consider checking that you have provided evidence that their copyright owners have agreed to license their works under the tags you supplied, too. You can find a list of files you have uploaded by following this link. Files lacking evidence of permission may be deleted one week after they have been tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you. MBisanz talk 02:11, 22 July 2009 (UTC)

MS-DOS 1.0Edit

It used the FAT-12 filesystem on 160kb single-sided 8-sector 5¼"-inch floppies. It was extremely primitive in some respects, yet still a great advance over commonly-used CP/M filesystems, since the exact file length, file modification date and time, etc. were recorded. Subdirectories were added in DOS 2.0, yet the DOS 1 directory entry format remained unchanged until the introduction of LFNs in Windows 95... AnonMoos (talk) 12:29, 2 December 2009 (UTC)

UTF-16Edit

Hi, I reverted you deletions in UTF-16, see edit summary. Probably you have a point in some deletions, but I did not see that in the whole. btw for my understanding, the thing "word" (as a bitlength unit) is not used in Unicode, so that makes it hard to understand for me. -DePiep (talk) 22:48, 21 June 2010 (UTC)

UTF-8's compactnessEdit

Hi, I noticed you removed my addition to UTF-8 explaining that UTF-8 is popular in part because it is more compact than UTF-16 and UTF-32. I don't understand why, though, because the current wording (which is the same, or very nearly the same, as what it said before I added this part) suggests that the compactness of UTF-8 for Western European languages is not a significant reason for its popularity, because it cites its ASCII compatibility as the only reason ("for this reason", to me, suggests no other possible reasons), which I have a bit of a hard time believing. You also said "lots of other rejected multibyte encodings are shorter", but I don't understand why that's relevant or even what these encodings are... - furrykef (Talk at me) 00:32, 14 October 2010 (UTC)

I believe the reason for UTF-8 popularity is the ASCII compatibility, not compactness. An encoding that reused the ASCII bytes as part of larger characters would be more compact, and this is what most alternatives to UTF-8 did. (the other reason is that other multibyte encodings did not map all of Unicode or made the mapping hard to figure out). Comparing it to UTF-16 for size here does not make sense, as the reason it wins over UTF-16 is certainly compatibility, UTF-16 is incompatible with every single possible ASCII string!
I don't see why non-Unicode encodings are relevant here. When we talk about the popularity of UTF-8, I think one would generally assume "as opposed to other Unicode encodings", since, as you said, non-Unicode encodings generally don't cover the Unicode set.
In any case, I think my main issue here is that you seem insistent on citing compatibility as the only reason for UTF-8's popularity over UTF-16. Surely the size factors into it at least a little? If I were to store big heaps of Japanese text, for example, I would use UTF-16 (unless I thought there was a high probability that the files would need to be used with a program that only understands UTF-8). - furrykef (Talk at me) 03:48, 15 October 2010 (UTC)

License tagging for File:Unicode 2400 Chrome Ubuntu.pngEdit

Thanks for uploading File:Unicode 2400 Chrome Ubuntu.png. You don't seem to have indicated the license status of the image. Wikipedia uses a set of image copyright tags to indicate this information; to add a tag to the image, select the appropriate tag from this list, click on this link, then click "Edit this page" and add the tag to the image's description. If there doesn't seem to be a suitable tag, the image is probably not appropriate for use on Wikipedia.

For help in choosing the correct tag, or for any other questions, leave a message on Wikipedia:Media copyright questions. Thank you for your cooperation. --ImageTaggingBot (talk) 07:05, 26 October 2010 (UTC)

ARF CLI GUI etcEdit

Please respond at: Talk:Abort, Retry, Fail?#Take two. —DragonHawk (talk|hist) 11:38, 24 March 2011 (UTC)

Still waiting. Please respond. —DragonHawk (talk|hist) 02:15, 4 May 2011 (UTC)

ImposterEdit

I blocked and cleaned up after that person who was trying to impersonate you. -- Gogo Dodo (talk) 05:50, 8 April 2011 (UTC)

I don't understand.Edit

Can you explain your checkin note in the NeWS article? You added "Actually pure PS could not no matter how much helped", but I can't understand what this means in the context of the edit. Maury Markowitz (talk) 11:07, 28 June 2011 (UTC)

Actually I'm not sure. It may make sense, but it seemed to me that the added text was just useless filler that provided no information. NeWS itself "needs additional software" (ie the operating system, probably other stuff) in order to work, too. I'm guessing you are saying that DPS could be used for windows provided you use something else for creating the windows and handling all the i/o, but when you specify it that way it is a true statement for any library, that it could be *part* of a windowing system. You could argue that DPS is designed for output, but when you do that you have to define X11 as being part of it in which case you might as well claim they are integrated and thus DPS+X11 is capable "without additional software".
Ahhh. OK I do believe this still needs mentioning in the article, but I'll fix the context. Maury Markowitz (talk) 12:12, 29 June 2011 (UTC)
Actually you're right, in the intro it's not needed at all. Maury Markowitz (talk) 12:14, 29 June 2011 (UTC)

i'm not getting why you have deleted the information on the page strcat from the section strcat_s. here i'm going to undo it. if you have any problem tplease drop message on my talk page. and give your suggestions. == Prasannjit Gondchawar (talk) 19:16, 1 October 2011 (UTC)

about deletion of the information from the section strcatEdit

i'm not getting why you have deleted the information on the page strcat from the section strcat_s. here i'm going to undo it. if you have any problem tplease drop message on my talk page. and give your suggestions. == Prasannjit Gondchawar (talk) 19:17, 1 October 2011 (UTC)

Disambiguation link notification for March 13Edit

Hi. When you recently edited Code page 437, you added links pointing to the disambiguation pages !! and 1/4 (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) 10:58, 13 March 2012 (UTC)

"Seek is O(1) in code units."Edit

Can you give an algorithm demonstrating that? To find the nth character, do you not have to examine the preceding ones to determine that you indeed have the nth? (Of course, there are other issues here as well: the O(1) algorithm for char* is obviously at risk for buffer overruns, e.g., unless you have a solid upper bound, and can be fooled even then.) -- Elphion (talk) 16:27, 21 April 2012 (UTC)

Oh, I see: I was misreading "code unit" as "character". But this is not interesting: no one is interested in seeking to the nth code unit unless you already have something like a lut for the string converting Char(n) into CU(m) (or more broadly, a list of starting points that you interested in -- beginning of paragraphs, etc. -- i.e., something you get by already having scanned the text). -- Elphion (talk) 16:32, 21 April 2012 (UTC)
I should be clearer: I am "on your side" here -- the argument that UTF8 or UTF16 strings can't be treated as arrays is a red herring, because strings shouldn't be treated as arrays until they have been thoroughly scanned. If one truly needs an array of the characters, it can be built during the scan. But the argument that seeking the nth CU is O(1) is irrelevant to this. -- Elphion (talk) 16:53, 21 April 2012 (UTC)
The mistake you are making is thinking that there is a need to count "characters" at all. First of all the word "character" is poorly defined in Unicode (it depends on the interpreted normalization and quite a few code points may not be "characters" so it is impossible to count them except by string scanning, in any encoding. I suspect however you mean "Unicode code points" when you say "characters". Or perhaps "UTF-16 code units" (where Unicode code points greater than U+FFFF are 2 units). I hope you can see from even these few examples, where I am unsure what you intend, why talking about "characters" is a bad idea.
In any case this makes as much sense as saying there is a need to find the N'th word or letter 'x' or anything else in O(1) time. There is no need for this, and text processing is quite fast despite the inability to do searches in less than linear time. The problem is that you need to remember *offsets* into strings and it is desirable to turn an offset into a pointer to the character in O(1) time. The obvious solution that any programmer should think of is to use fixed-size units for this "offset", in fact it is such a no-brainer that it seems hard to believe anybody would ever think otherwise. However decades of indoctrination where every man page says "characters" when talking about offsets seems to have turned even experienced programmers into complete morons when they encounter UTF-8.Spitzak (talk) 01:57, 24 April 2012 (UTC)

Talk:UTF-8 #Byte vs OctetEdit

[1] Please, restrain from personal attacks and assuming a bad faith, especially if there are no on-wiki evidences. Even if you allege to know something important about the real-life identity of that user, Wikipedia does not serve for spreading such rumours. Incnis Mrsi (talk) 06:04, 8 May 2012 (UTC)

Yes sorry, that was stupid. It was obviously a good-faith edit.Spitzak (talk) 22:59, 8 May 2012 (UTC)

UCS2 and UTF-16Edit

Just curious: why is UTF-16 not an extension of UCS2? While it's true that the codepoints assigned to surrogate pairs are no longer available in UTF-16, those values had no character assignments in UCS2, so they did not lose their "original meaning". Are there other codepoints that were sacrificed in the transition? -- Elphion (talk) 21:09, 13 July 2012 (UTC)

LexicographicEdit

Hi -- not arguing the merits of your change, but pointing out that since the wording was being discussed on talk page, that's where you should have floated the change. Otherwise it's a quick descent into edit warring! -- Elphion (talk) 13:04, 18 September 2012 (UTC)

EBCDICEdit

You said

You really think "accustomed to ASCII" is why this was confusing? Really? Give me a break

Before EBCDIC and ASCII were developed, Variants of BCD were the most common character codes, and they all have non-contiguous alphabets smilar to EBCDIC, so EBCDIC probably wouldn't have been confusing then. I do think it was only after programmers becaame used to ASCII that anyone even gave it any thought. I've posed it as a question on the EBCDIC talk page. Peter Flass (talk) 22:46, 21 September 2013 (UTC)

EBCDICEdit

You said

You really think "accustomed to ASCII" is why this was confusing? Really? Give me a break

Before EBCDIC and ASCII were developed, Variants of BCD were the most common character codes, and they all have non-contiguous alphabets similar to EBCDIC, so EBCDIC probably wouldn't have been confusing. I do think it was only after programmers becaame used to ASCII that anyone even gave it any thought. I've posed it as a question on the EBCDIC talk page. Peter Flass (talk) 22:46, 21 September 2013 (UTC)

NakEdit

Please don't remove sourced content. A "nak" is a female "yak" - it's in the yak article. Rklawton (talk) 03:13, 23 October 2013 (UTC)

About the slashesEdit

About Slash_(punctuation)#Encoding. The facts are clear (including the Unicode mislead), but I think we could get the prose better.

How about the section intro setup like: "Slashes are encoded in Unicode as ... and ...". But the Unicode naming is controversial/disputed.

(then the next paragraph says:) Typographically ... (zoom in on diffs).

One issue is, we should not push both definition and naming issue in one paragraph "encoding". What do you think? -DePiep (talk) 18:26, 17 April 2014 (UTC)

UTF-8 and ASCII backward compatibilityEdit

Hello there! Regarding our recent back-and-forth on UTF-8 and ASCII backward compatibility, please allow me to explain.

In a few words, a text editor which is only ASCII-aware can be used to process 7-bit ASCII subset of the UTF-8 data only, for example, and everything else is pretty much garbled to the end-user using such a text editor. If we take an API client as another example, it can also understand 7-bit ASCII subset only; everything else is garbage to anything speaking only ASCII, and any changes performed outside the 7-bit ASCII subset are going to break UTF-8's multibyte characters.

Hope it makes sense, and of course, I'm more than open to discussing this further. — Dsimic (talk | contribs) 06:58, 22 April 2014 (UTC)

"processing text" does NOT mean "text editor". What I meant is that code like this:
 printf("<some utf-8 here> %d\n", 10);
will work even if the C compiler and library does not know anything about UTF-8. The only requirement is that bytes with the high bit set are passed unchanged by the compiler, printf, and the output driver (it will help if the output is drawn on a terminal that understands UTF-8, but even if it is redirected to a file that is eventually displayed on a UTF-8 aware editor this works). This is true of virtually every language written to handle ISO-8859-1 or even the older IBM PC code pages.
Claiming the program must know something about the code point boundaries is as false as claiming it is impossible to process English text unless the program includes an english dictionary.— Preceding unsigned comment added by Spitzak (talkcontribs)
You're absolutely right with the above printf() example, and a bit later I'll change the wording in the article so it's covered. — Dsimic (talk | contribs) 15:23, 22 April 2014 (UTC)
Just saw that you've already reverted my edits. Well, you can have it that way if you insist, though saying that ASCII-aware software "can process UTF-8 data as well" is somewhat misleading, as "processing" isn't well defined and can mean many things. — Dsimic (talk | contribs) 15:28, 22 April 2014 (UTC)
Well, as always, things aren't that simple. For example, what if we had something like this, what's perfectly fine to be expected from an ASCII-aware application handling some ISO-8859-1 text:
printf("<some utf-8 here> %s\n", "<some iso-8859-1 here>");
That's happily producing invalid UTF-8 output. Thoughts? — Dsimic (talk | contribs) 15:40, 22 April 2014 (UTC)
That example will still produce correct UTF-8 both before and after the ISO-8859-1 text. Depending on what is reading the output you will either see error indicators inside that text, or it will be recognized as ISO-8859-1 and rendered correctly.Spitzak (talk) 18:38, 22 April 2014 (UTC)
How can UTF-8 be recognized as ISO-8859-1? — Dsimic (talk | contribs) 18:46, 22 April 2014 (UTC)
Because it won't be valid UTF-8 (unless it is ASCII or an extremely unlikely arrangement of two or three letters and symbols in a row). This error can be detected by looking at no more than 4 bytes in order to determine that the first byte must not be the start of a UTF-8 character, there is no need to find the "ends" of the ISO-8859-1, this is strictly a one-pass algorithm. The display can then do something with this byte, such as show an error indicator, or guess that it is in ISO-8859-1 (or CP1252). It can then continue interpreting with the next byte, which will allow this to repeat if there is a long sequence of non-UTF-8 in the text. This will re synchronize correctly on the next valid UTF-8 code point.Spitzak (talk) 19:13, 22 April 2014 (UTC)
That's all fine, but the point is that using ASCII-aware software provides forward compatibility with UTF-8 only in case 7-bit ASCII characters are used in combination with untouched multibyte UTF-8 characters. Why would those 128+ single-byte characters have to be ISO-8859-1 or CP1252? Why wouldn't they actually be Windows-1253, for example? Anything beyond 7-bit ASCII is a plain guessing game, if you agree. — Dsimic (talk | contribs) 19:33, 22 April 2014 (UTC)
Sure, but I fail to see what a "UTF-8 aware" program could do that is any better if it is given a block of bytes that is not UTF-8. Yea it can throw an exception, but IMHO that is *worse*, not better. The trivial operation of copying a block of bytes that is IMPOSSIBLE to confuse with valid data is the correct behavior.Spitzak (talk) 23:50, 22 April 2014 (UTC)
Well, I'd say that we're pretty much on the same page, and the whole confusion came from the vague definition of "processing". At the same time, the subset of bytes that can't be mistaken (in both directions) is the 7-bit ASCII. If it goes into 8-bit ASCII, backward/forward compatibility breaks due to design of UTF-8. Agreed? — Dsimic (talk | contribs) 02:59, 23 April 2014 (UTC)
Yes, any program that assigns a meaning to an 8-bit byte will fail to handle UTF-8, mostly because they may change this byte to a different value. The biggest problems are programs that make NEL (0x85) and non-breaking space (0xA0) into whitespace characters. But there is a lot of programs, in particular both compiled and interpreted languages, that assign no meaning to any bytes between quotes in a string constant other than the quotes and backslash, which are ASCII.Spitzak (talk) 03:22, 23 April 2014 (UTC)
... and other than dollar signs and curly brackets – as that's the case for PHP, for example, which is still good. — Dsimic (talk | contribs) 03:42, 23 April 2014 (UTC)

Du erhältst einen Orden!Edit

  Der Detailorden
For your FLTK change Polluks 12:10, 28 August 2014 (UTC)

Reversion without explanationEdit

When you revert a good-faith edit (as you did here), it's best to provide a reason for the reversion. Otherwise the editor whose edit you reverted can't learn from their mistake. In this case, your reversions seem pretty low-effort, given that you could have also fixed the other occurrences of the word "octet" since you feel it's so obviously obscure and unused. When reverting good-faith edits, I'd encourage you to improve the page if the edit was prompted by inconsistency (as in this case) or some other easily-fixed problem. Electricmuffin11 (talk) 07:28, 24 September 2014 (UTC)

November 2014Edit

{{subst:User:BracketBot/inform|diff=635280213|page=Control character|by= by modifying 1 "()"s|debug=(-1, 0, 0, 0)|list=yes|remaining=*[[newline|CR and LF]] used to separate lines of text. The code 127 ([[Delete character|DEL]])) is also a control character. [[Extended ASCII]] sets defined by [[ISO 8859]] added the codes 128

  • character|escape]], <code>ESC</code>, <code>[[\e]]</code> ([[GCC (software)|GCC]] only), <code>^[</code>).
  • normally. For example, the sequence of code 27, followed by the printable characters <nowiki>"[2;10H", would cause a DEC VT-102 terminal to move its [[cursor (computers)|</nowiki>
  • with 31, forcing bits 6 and 7 to zero. For example, pressing "control" and the letter "g" or "G" (code 103 in [[octal]] or 71 in [[decimal|base 10]], which is 01000111 in [[Binary numeral system|

|lines=4}}

Please, a little lighter on the hammer!Edit

I realize your recent edits to the ANSI article are all in GF, but you deleted/reverted considerable useful formatting and ancillary information while in the process of deleting what you feel is "totally wrong". For instance, you deleted the statement that VT52 clones were made as part of that "totally wrong" edit, which I think you would agree is not "totally wrong". Please, a little lighter on a reverts! Maury Markowitz (talk) 17:23, 22 January 2015 (UTC)

ArbCom elections are now open!Edit

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) 12:49, 23 November 2015 (UTC)

April 2016Edit

  Hello, I'm BracketBot. I have automatically detected that your edit to String (computer science) 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 my operator's talk page.

List of unpaired brackets remaining on the page:
  • a total order on Σ<sup>*</sup> called [[lexicographical order]]. For example, if Σ = {0, 1} and 0 < 1, then the lexicographical order on Σ<sup>*</sup> includes the relationships ε < 0 < 00 < 000 < ... < 0001 < 001 < 01 < 010 < 011 < 0110 < 01111 < 1 < 10 < 100 < 101 < 111 < 1111 < 11111 ... The lexicographical order is [[total order|total]] if the alphabetical order is, but isn'
  • htm |archivedate=August 15, 2015 }}</ref> since this was the string delimiter in its BASIC language).

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 22:40, 4 April 2016 (UTC)

Yea, maybe you need to remove yourself from the ANSI page. You have reverted an improvement.Edit

(Undid revision 737919284 by TiredTendencies (talk) "Replacement text is not better, seems to imply that you must type a zero"

That's because you must type a zero. ??? What is the confusion here? It not only implies you must hit numpad 0,. but it suitably states such.

ALT+0 # # # where # # # are 3 numbers from the old DOS alt codes. To get the same alt code character, you must now add a zero in front of the original alt code. Not sure what the confusion here is. Was more re-placing 'citation needed' to proper spots either way. The reversion you completed has now made the CN marks in incorrectly suggestive places as to WHAT exactly needs a citation.


And yes, it seems to imply you must hit the numpad 0 (as I stated with my edit, specifically using the word 'numpad'). Why? Because YOU MUST HIT THE NUMPAD ZERO to access original DOS alt codes at their original alt code numbers! Perhaps it should not imply, perhaps it should simply STATE that you must do so. Because you must.

Might be time to take the ANSI page off your watchlist. Articles belong to nobody and it is clear from reading your talk page you have aggressively reverted this article multiple times for no real reason. You even have a 'give a reason for edit reversion in good faith' listing here. TiredTendencies (talk) 23:36, 5 September 2016 (UTC)

No, you hit zero first to use the *NEW* codes. If there is no leading zero you get the old cp 437. Your text is implying the opposite.

ArbCom Elections 2016: Voting now open!Edit

 Hello, Spitzak. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

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 2016 election, please review the candidates' statements and submit your choices on the voting page. Mdann52 (talk) 22:08, 21 November 2016 (UTC)

ArbCom Elections 2016: Voting now open!Edit

 Hello, Spitzak. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

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 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)

Unicode terminology - BOM vs. Signature, code unit, ...Edit

For the term Unicode Signature, see http://www.unicode.org/versions/Unicode9.0.0/UnicodeStandard-9.0.pdf, chapter 2.13 Special Characters ("Unicode Signature. An initial BOM may also serve as an implicit marker to identify a file as containing Unicode text. ") and the following tables: Table 23-6, Table 23-7

A code point is the abstract form of a character, irrespective of its encoding.

A specific method of encoding code points, irrespective of endianness, is an encoding form.

A code unit is the basic unit of encoding in a given encoding form: one or more code units encode a single code point: 1-4 units in UTF-8, 1-2 units in UTF-16 (if 2 units are needed, they're called a surrogate pair), ...

An encoding form with specific endianness is an encoding scheme.

Strictly speaking, BOM is the single code point (character) U+FEFF, irrespective of its encoding.

The byte sequence that results when you encode the BOM character using a specific encoding scheme is what is loosely also called a BOM. More accurately, such a byte sequence is an encoding of the BOM character.

However, given that these byte sequences are also used to identify encoding schemes to which the concept of byte order doesn't apply - such as UTF-8 and UTF-7, which use bytes as the code units - it is better to call these byte sequences Unicode signatures.

Tabledhote (talk)

tabEdit

So fixing the image might be a good idea , reverting to previous version is not the best solution. DGerman (talk) 22:40, 3 May 2017 (UTC)

Regarding Revert of changes on UTF-8Edit

Diff: https://en.wikipedia.org/w/index.php?title=UTF-8&oldid=prev&diff=781055797

Your comment is """Apparently not valid UCS-2, those code points are called "invalid" in *all* unicode forms)""", which is not correct. As you can see in https://en.wikipedia.org/wiki/UTF-16#U.2BD800_to_U.2BDFFF , """UCS-2, UTF-8, and UTF-32 can encode these code points in trivial and obvious ways""", and in fact, *this* is the difference between UTF-16 and UCS-2: UTF-16 doesn't encode the surrogates range (<U+D800..U+DFFF>), but encodes non-BMP characters (<U+10000 to U+10FFFF>), but UCS-2 encodes the surrogate code points (<U+D800..U+DFFF>), but nothing out of BMP. Behnam (talk) 22:15, 18 May 2017 (UTC)

Unicode has declared that the code points for surrogate halves are invalid. They are equally unable/able to be encoded in UCS-2 as UTF-16. It is trivial to insert these codes into *both* encodings, which means any "validity" is equal in both. If a high and low surrogate half happen to be next to each other, most of modern Windows will interpret that as a single Unicode code point, therefore the text is UTF-16, not UCS-2 (which would require Windows to interpret it as two invalid code points).Spitzak (talk) 23:18, 18 May 2017 (UTC)
Unicode Surrogate Pair characters are not "invalid code-points", they are "valid code-points" of type Surrogate, but, yes, they are not "Unicode Scalar Values". (See http://unicode.org/glossary/#unicode_scalar_value , http://unicode.org/glossary/#code_point and http://unicode.org/glossary/#code_point_type). Anyways, the whole point of my change was to help readers understand why those code-unit/code-points are allowed in Windows and other systems in the first place (because they were based on UCS-2, before UTF-16 existed), where those values are valid code-points. Behnam (talk) 05:10, 19 May 2017 (UTC)
The reason they are allowed in Windows filenames is that it is VASTLY simpler to implement the file system that way. Not for any idea of whether a code point is "valid" in Unicode. Several valid code points like '/' are not allowed in the filenames (I believe, though possibly the Win32 api has a non-path api to name files which would allow these too). A huge problem currently is code that believes these code points will magically not happen because they are "invalid" or whatever, and saying that changing to UCS-2 verses any other encoding somehow changes these code points validity is IMHO very harmful to getting the idiot savants who write things to stop doing such stupid actions.

ArbCom 2017 election voter messageEdit

 Hello, Spitzak. Voting in the 2017 Arbitration Committee elections is now open until 23.59 on Sunday, 10 December. All users who registered an account before Saturday, 28 October 2017, made at least 150 mainspace edits before Wednesday, 1 November 2017 and are not currently blocked are eligible 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 2017 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 3 December 2017 (UTC)

UTF-16Edit

Thanks for clearing that up. It was completely opaque before; I guessed one interpretation, trusting that someone would correct it if I guessed wrong! -- Elphion (talk) 06:01, 12 April 2018 (UTC)

Yes, chcp 65001 is a thingEdit

(Moved to Talk:Unicode_in_Microsoft_Windows#Yes, chcp 65001 is a thing)

--Artoria2e5 contrib 16:29, 9 May 2018 (UTC)

Disambiguation link notification for June 5Edit

Hi. Thank you for your recent edits. An automated process has detected that when you recently edited Meta key, you added a link pointing to the disambiguation page Super key (check to confirm | 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) 09:48, 5 June 2018 (UTC)

HP 2000AEdit

I undid your redo on the 2100 article that stated the 2000A was a dual-CPU machine. It was not, see ftp://ftp.mrynet.com/pub/os/HP2000/pdf/02000-90003_sitePrep_Nov69.pdf. The dual-CPU configurations started with the 2000B; it would have been difficult to fit two machines into the A model due to its much larger core. Maury Markowitz (talk) 11:20, 10 July 2018 (UTC)

Was just restoring some old text, I have no idea. It sure sounded like there was one computer that ran BASIC, and another that did all the I/O to the terminals.Spitzak (talk) 18:31, 10 July 2018 (UTC)

ASCII in UTF-8Edit

ASCII is listed separately normally like here: <0.1% https://w3techs.com/technologies/history_overview/character_encoding/ms/y — Preceding unsigned comment added by 2003:CA:A72D:2000:9B2:9B82:511:8F06 (talk) 21:16, 6 September 2018 (UTC)

Ordinal indicatorEdit

Understood, now. Thanks! Code Page Guy (talk) 11:22, 19 September 2018 (UTC)

Stop you removal of information from the character set tablesEdit

Spitzak, some weeks ago you made bold changes to some character set / code page tables (including ASCII) which were reverted because there is no consensus for them. Some of your proposed changes would have made the tables basically useless, as has been explained to you several times (f.e. Talk:ASCII#New_smaller_table).

I now see that you have nevertheless mass-removed vital information from the tables and applied your changes to character set articles all over Wikipedia without consensus. You have thereby destroyed much of the utility value of these tables.

I firmly ask you to stop this disruptive behaviour immediately. It is extremely annoying to see wasted the precious time and energy of other editors who researched and added the info in the first place and will now have to try and restore the information again. --Matthiaspaul (talk) 14:50, 23 September 2018 (UTC)

You NEVER posted any comments! Do so! I had an example of this up for a month Talk:ISO/IEC_8859-1, after you rejected the one that had the unicode removed. I addressed every one of your objections, aind in fact ADDED numerous change boxes to the tables (whifch your blind reversiohs have deleted!!!). In particular on ASCII I directly asked for an example of information that has been deleted, and you have not said anything. All I can think is that you think a number that is trivially derived by multiplying the table row by 16 and adding the column is "vital" information???

I am going to have to revert the reversions you did where you destroyed the many fixes to the boxes, code entries, and numerical entries in the tables. Thanks a lot. You talk about "constructive" but you are doing the exact opposite.

I very much would appreciate you putting an example of destroyed information here, as I have been very careful to not delete any footnotes, multiple definitions, etc:

Thank you.Spitzak (talk) 19:54, 23 September 2018 (UTC)

I reverted a few but it is probably pointless as I expect you will revert them back. If you could try to preserve the work done to make the change boxes correct it would be nice, there were also a few glyph fixes (in particular in EBCDIC IBM puts slashes, not spaces, into the control character names). I also tried to make it consistent with a/b syntax for alternatives (a (b) was used in many cases but it is wider).

I have put on ISO-8859-1 my proposal for showing the decimal numbers, as you seem to think they are important. Possibly best to discuss this over there.

(edit-conflict) Spitzak, before you make mass-changes to the long established status quo, it is you who must find broad community consensus for them first, not me, who was (mostly) happy with the current presentation.
I already offered you my opinion at Talk:ASCII when the subject was brought up originally a few weeks back - but your proposed changes were so many and in some cases so extreme that I can't address all of them. With so many changes you seem to not like the tables at all - however, "as is" they are the long established standard for almost all character set tables in Wikipedia and the result of years of refinements.
If you would fix the few remaining shortcomings of the existing tables I would actually appreciate this, however, from what you wrote you obviously want something completely different than what the community has put together over the years.
You apparently want a small table optimized for smartphones, with as little information as possible, whereas I want them to be comprehensive and top-most reliable encyclopedic references useful for quick lookup (without mouse hovering) as well as for side-by-side comparisons or actual implementation work. The tables must provide all vital information at once, so that they could be printed out - tooltips or popup menus won't work.
You removed the decimal values from all the tables, which is unacceptable. The tables need to carry hex and decimal (and in some cases also octal) values to be useful.
I see that you are now mass-re-reverting me which means you have started to edit-war over changes for which you do not have community consensus. This is causing large-scale disruption of information which has been researched and put together over many years.
I hereby ask you to self-revert and find a community consensus first. If you continue to force your changes into the character set articles without a broad backing of the community, this will probably have to be escalated.
--Matthiaspaul (talk) 23:19, 23 September 2018 (UTC)
Regarding my reversions, I had to bring the character set tables back to the established status quo as soon as possible, because things become even more complicated to sort out and resync once other editors have edited the pages as well. Since you changed many things at once (and over so many articles) it was sometimes impossible to only roll back the disputed changes, in particular if there were newer edits already.
If you fixed actual bugs in the tables then please reapply them individually (and without the disputed changes).
Right now, I don't understand what you mean by "change boxes".
--Matthiaspaul (talk) 23:19, 23 September 2018 (UTC)
I mean boxes around characters that are different than some common reference character set, one of your primary requests for a replacement (see your comments in ASCII). These were edited in as I could run a diff with the saved text from the reference set.
The decimal numbers look like bloat to me and are trivial to calculate from the table location. In addition they are a continuous source of bad edits by people who think the decimal number and the hex number must be equal, and change one or the other to match. Use of decimal numbers to talk about code positions is almost non-existent in modern documentation as well. I really fail to see why you think this is important, and conversely why you don't see how distracting and ugly these numbers are. I would appreciate some examples where these numbers are actually used and the hex number is not also available (except for Alt codes which is why I left the numbers on DOS code pages).
I am not doing anything with smartphones, this is to compress it enough that a typical table fits on a desktop (they do fit on my 3K monitor but that still is not typical, and it would be really nice if *two* fit the 3K monitor.
I would appreciate a constructive comment, like alternative ways to display the information that does not distract from character identification. As you apparently do not look at samples in the talk pages, I have to resort to posting test edits in the pages so you will comment. My mistake was assuming your silence meant acceptance. Please take a look at ISO-8859-1 for another attempt to delete those hideous decimal numbers.

Spitzak (talk) 23:59, 23 September 2018 (UTC)

ISO-8859-1 has been reverted and re-edited with a few steps to a proposed new version. Please check it out. Also ISO-8859-2 and ISO-8859-3 have been reverted and the box and spelling changes applied but leaving the decimal numbers in. It is easier than I though to remove the decimal numbers, they don't have to be deleted. That would have made reversion with saving the edits much easier. Spitzak (talk) 04:58, 25 September 2018 (UTC)

I will review your proposals when I have time for it again. Someone broke into the house, so I have other obligations right now.
If you find actual bugs, please reapply them. Still, you should not remove the decimal values or make other potentially controversial changes, because there's no community consensus for this. If you do (as you unfortunately did already despite being told not to do it), this constitutes as edit-warring, and it is not covered by WP:BRD, in particular not for mass-changes all over the place. That's why I asked you to show your good will and try to clear you from the status of being an edit-warrior by self-reverting those edits ASAP and only reapply the actual bug-fixes, so that a constructive discussion without deadline can take place (ideally on the article talk page) before other changes can be possibly applied to the articles (but only if community consensus can be found for them). Thanks.
--Matthiaspaul (talk) 09:17, 26 September 2018 (UTC)

ARBIPA sanctions alertEdit

 This is a standard message to notify contributors about an administrative ruling in effect. It does not imply that there are any issues with your contributions to date.

You have recently shown interest in India, Pakistan, and Afghanistan. Due to past disruption in this topic area, a more stringent set of rules called discretionary sanctions is in effect: any administrator may impose sanctions on editors who do not strictly follow Wikipedia's policies, or any page-specific restrictions, when making edits related to the topic.

For additional information, please see the guidance on discretionary sanctions and the Arbitration Committee's decision here. If you have any questions, or any doubts regarding what edits are appropriate, you are welcome to discuss them with me or any other editor.

Kautilya3 (talk) 11:53, 23 October 2018 (UTC)

ArbCom 2018 election voter messageEdit

 Hello, Spitzak. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible 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 2018 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 19 November 2018 (UTC)

Roman Numerals (rules)Edit

I've cut to new section(s) on this long running battle - just a little concerned that your comment might get lost from being stuck on the end of the old one? In fact I nearly moved your last remark down to the bottom, but of course this is (rightly) against the guidelines. Anyway, do make sure you have a look at the current situation at the bottom of the page. Xcalibur's rules, I think we agree, are totally unusable - I have substituted by own idea of what a set of rules might look like - including the rule itself (in simple, unambiguous terms) followed by notes and examples where necessary. But I really think I did a fair job in getting rid of the rules altogether and I still haven't seen a coherent argument to the contrary! --Soundofmusicals (talk) 03:59, 21 November 2018 (UTC)

EBCDIC againEdit

for (c='A';c<='Z';++c)

becomes

char alfa="ABCD...WXYZ"; for(i=0;i<=25;i++)<ref to alfa[i] instead of c>

No procedure call required. Not much of a change. Apologies for not remembering C very well, I haven't used it in years. Peter Flass (talk) 17:03, 21 November 2018 (UTC)

That requires keeping an extra variable that is unnecessary in ASCII and occupies 27 bytes one of which is unused. This sort of stuff is exactly what programmers hated back in the day.Spitzak (talk) 19:04, 21 November 2018 (UTC)
 :-{ Peter Flass (talk) 19:27, 21 November 2018 (UTC)

December 2018Edit

  You currently appear to be engaged in an edit war according to the reverts you have made on Arabic numerals; that means that you are repeatedly changing content back to how you think it should be, when you have seen that other editors disagree. Users are expected to collaborate with others, to avoid editing disruptively, and to try to reach a consensus, rather than repeatedly undoing other users' edits once it is known that there is a disagreement.

Points to note:

  1. Edit warring is disruptive regardless of how many reverts you have made;
  2. Do not edit war even if you believe you are right.

If you find yourself in an editing dispute, use the article's talk page to discuss controversial changes and work towards a version that represents consensus among editors. You can post a request for help at an appropriate noticeboard or seek dispute resolution. In some cases, it may be appropriate to request temporary page protection. If you engage in an edit war, you may be blocked from editing. Kautilya3 (talk) 15:04, 1 December 2018 (UTC)

Alt-keycodes insightEdit

Thanks for your input on pound sign. Your comment (in the edit history) that "on some setups any number equal to 156+n*256 will work, so this is in fact redundant with the 156 example" is interesting, and possibly interesting enough to be included within the article itself, or maybe a more general article such as Windows Alt keycodes - as there are several websites suggesting Alt-6556, and this could be clarified. But can you provide any references to demonstrate that this +n*256 principle is true? And is there a way of determining when (i.e. in which combination of codepage/default locale/language_used_for_non-Unicode_programs/IME/language settings/typeface etc. etc.) this particular combination will produce the pound sign? In my own case (see e.g. Talk:Pound_sign#Explanation_for_Alt_keycode_6556?, I am frequently (but rather randomly: I cannot detect the pattern) unable to enter it via any combination of Alt- 156/0163/6556 etc. As demonstrated at the talkpage, it seems to be connected with codepage 850, but as to why, that is still unclear too. Ozaru (talk) 12:32, 15 December 2018 (UTC)

Created a safe wiki for Unicode subsetsEdit

Guy Macon is a digital version of a murderer. Safe information for Unicode subsets such as WGL4 is now found at https://unicode-subsets.fandom.com/wiki/Unicode_subsets_Wiki . 181.10.158.74 (talk) 11:24, 12 January 2019 (UTC)

XIX and XVIIIIEdit

Re your reversion of my edit to Roman numerals: as attested by all the examples cited in the article and in the talk pages, "XVIIII" has always been an acceptable way to write "19", from the Roman times (check Julius Caesar) through medieval times. Ditto for the other additive notations for digits 4 and 9, such as VIIII, XIIII, XXXX, LXXXX, etc. The subtractive notations "IV", "IX", "XL" have always been regarded as abbreviations of the additive ones, not as the only "right" way to write those numbers; much like we see "Dr." as merely an abbreviation of "Doctor", not as having superseded it. The Romans almost always used the subtractive notation for the same reason that we almost always write "Dr. Smith" instead of "Doctor Smith": because it saved 50% or more in strokes, time, and space. The only exception is IV, that saves only 25% on all three counts; and that is obviously why "IIII" is much more common than "VIIII" or "XXXX".
Note, for example, that the longest additive numeral from 1 to 12 is "VIIII", that takes the space of six "I" letters. If a clockmaker were to use additive notation for all numbers he would have to leave that much space for each numeral. If he uses "IX" for 9 instead, the longest numeral will be "VIII", that takes only five "I"-slots -- quite a bit easier to fit, and wasting much less space overall. But then using "IV" instead of "IIII" makes no difference, except saving a little bit of metal; and "IIII" looks nicer because it visually balances the "VIII" on the other side.
On the other hand, notations like "IIXX" and "IIX" (or "XIIX") are extremely rare, and their contexts indicate either linguistic induction (as in Romans saying "duodevigesimo" = "two-from-twentieth" for "18th", or "duoetvicensimo" = "two-and-twentieth" for "22nd") or simple scribal/stonecutter error. As for the former, it seems that the 18th and 22nd Roman Legions were often written as "XIIX LEGIO" and "IIXX LEGIO", respectively.
There is even an example where a stonecutter was commissioned to chisel "IIXX LEGIO" for "22nd Legion" but "autocorrected" that to "XVIII LEGIO" instead. (See the Talk page for the source.). So, while no one ever mocked Caesar for writing "XVIIII" and the like all over De Bello Gallico, we must conclude that at some time in the late Roman Age there was at least one adult human in the Roman Empire who felt that "IIXX" was definitely "wrong". (Just as we must conclude that there is at least one cow in Scotland that is black on the left side.)
All the best, --Jorge Stolfi (talk) 01:49, 3 May 2019 (UTC)

XVIIII is talked about in another paragraph as an alternative. I notice that paragraph does not say "instead of IXX" so there is precedent for not listing every possible alternative when describing each of them.Spitzak (talk) 17:47, 3 May 2019 (UTC)
The point is that, based on copious evidence from actual texts, Roman and Medieval authors would consider both "XIX" and "XVIIII" as valid alternative ways to write "19"; whereas they apparently regarded "IXX" as "wrong". So I was trying to say "instead of the commonly accepted forms". --Jorge Stolfi (talk) 22:45, 3 May 2019 (UTC)
I agree, it's just that the section that says "XVIIII is sometimes used instead of XIX" does not say "XVIIII is sometimes used instead of XIX or IIXX". Same should be true of this one. If there are N alternatives there is no reason to write N paragraphs, each saying "x is used instead of x1, x2, ...xN".Spitzak (talk) 23:15, 3 May 2019 (UTC)

CD versus CCCCEdit

Just to pick a nit,

  • "CD" is normally written with 3 strokes with same total length as ~5 "I"s, and uses the space of 4 "I"s
  • "CCCC" is 4 strokes with total length ~8 "I"s, and uses the space of 8 "I"s.

So the savings for "CD" are 25% in stroke count (roughly a measure of writing effort/time), ~38% in total stroke length (a measure of chiseling work and metal requirement) and 50% in space. That is why I had not claimed a flat "50% savings" for it.
All the best, --Jorge Stolfi (talk) 07:48, 17 May 2019 (UTC)

Yes but this "50%" in stroke count is wrong for several of the other samples as well. I'm not sure where this "stroke count" stuff came from, in all examples I have seen the one with less "stroke count" also has fewer characters. For instance you could say "stroke count" is why "IIV" is not used instead of "III" but "IIV" also has just as many characters. About the only interesting fact is that "IIII" is not twice as wide as "IV" which may explain why "IIII" is used more often than other alternatives.Spitzak (talk) 19:35, 17 May 2019 (UTC)

"Common patterns" in Roman numeralsEdit

Hi – in your latest edit to Roman numerals you changed:

"but these are arranged in a common pattern that remains constant for each power or "place".

To:

"but a common pattern is used for each of them".

I can live with this, to be honest – in spite of recent accusation of WP:OWN I do try to make a habit of only reverting well-meant edits when important information has been lost, or a misleading or frankly erroneous impression has been created.
On the other hand my original wording in this case was very carefully considered – in the light of persistent misunderstanding of what the paragraph was actually about (it is always safe to assume, I suspect, that the well-intentioned editor is less, rather than more liable to confusion than the average reader). In particular, I was a little apprehensive that my use of the phrase "common pattern" might be misunderstood, especially by a careless reader, or one with a less than perfect command of English.
Obviously, you understood perfectly exactly what I meant, and were able to put it more succinctly, but I do wonder if on reflection you might conclude that the original, while a few words longer, has the advantage of clarity?
Leave this one with you, anyway... ---Soundofmusicals (talk) 01:26, 22 May 2019 (UTC)

Undo to UTF-16Edit

Hi there! Regarding your edit here https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=prev&diff=902560464, the RFC says "SHOULD", which in the language of RFCs explicitly means a recommendation. In section 1.2 of the mentioned RFC, it says 'The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119', and RFC 2119 says '3. SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.' Do you disagree that the "plain English" meaning is closer to recommend? DimeCadmium (talk) 06:32, 30 June 2019 (UTC)

re ®Edit

For Registered trademark symbol: Please please go to the talkpage. You know how we do things at enwiki. -DePiep (talk) 22:28, 17 July 2019 (UTC)

Copyright symbolEdit

Do you have a cite for the "many fonts draw the copyright symbol as a superscript" you recently added in "Copyright symbol"? I've been doing a clean-up and that's the last unsourced bit that needs attention. I attempted to ping you via edit summary, but I'm not sure that shows up as a notification. TJRC (talk) 14:55, 19 July 2019 (UTC)

No, I copied the information from the Enclosed R page, I also copied it to the registered trademark symbol article. It had no citation, though it does appear true in a few fonts such as the serif and sans serif ones in the browser. An explanation as to why Unicode did not reuse it when they really like to reuse as much as possible is needed. I deleted uncited and imho dubious text that circled C is used instead of copyright because the copyright is missing from some fonts (any such font would be missing the circled C as well!)Spitzak (talk) 20:59, 19 July 2019 (UTC)
The enclosed alphanumerics only references the entire Unicode standard when talking about the disunification.Spitzak (talk) 21:06, 19 July 2019 (UTC)
Thanks, I'll delete that bit then; it's not all that important to what the symbol is, anyway. Thanks for deleting the Korean bit; that's bothered me for a long time, and I never got around to trimming it. Most of the edit adding it was pretty much nonsense, and in retrospect, I should have cut the entire paragraph rather than just editing out the obvious falsities. TJRC (talk) 22:39, 19 July 2019 (UTC)

Pound signEdit

I have undone your reversion of reference to # in lead. Article is "pound sign", not "£" or pound sterling. For US readers, "pound sign" means "#". Per WP:LEAD, significant points in the body should be summarised in the lead. If you continue to disagree, please use talk:Pound sign to discuss. --John Maynard Friedman (talk) 11:55, 24 September 2019 (UTC)

Roman numeralsEdit

To say I am fed up with this article is an understatement - but last time I cut it from my watchlist the result was not good (!) In the meantime I have better things to do than field endless quibbles over precise wording. Current form of the article I can live with - so perhaps we could leave it there - at least until it gets attacked again. --Soundofmusicals (talk) 22:27, 18 November 2019 (UTC)

ArbCom 2019 election voter messageEdit

 Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. 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 2019 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 {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:04, 19 November 2019 (UTC)

Sidebar at ordinal indicatorEdit

For the currency signs, I was wp:BEBOLD and just commented out the punctuation sidebar. I felt strongly that it was just clutter in those articles and in some, like rouble sign, it had the horrible disruptive effect that you describe: compare the versions before and after I edited it today. Maybe you don't actually need it in ordinal indicator? --John Maynard Friedman (talk) 20:39, 20 November 2019 (UTC)

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

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)

Removal of *sidebars from punctuation pagesEdit

Hey, I noticed that you removed navboxes from (all?) pages on punctuation on December 11th. Just wondering why? It's been reversed on Full stop with no apparent attempt from you to counter it, so I'm unsure whether it's supposed to be that way or not. - Novelyst (talk) 10:45, 19 December 2019 (UTC)

I was replacing the "sidebar" with a new "navbox" at the bottom. The sidebar is far too big and interferes with images. I didn't revert because I wanted to see if there was consensus the navbox was better.Spitzak (talk) 15:54, 19 December 2019 (UTC)
Ah, I understand. From what I can see, however, the navbox does not appear to display all punctuation (as did the sidebars) - I see no full stop - or the exact names adjacent. From a more objective standpoint, wasn't the sidebar better in this regard? - Novelyst (talk) 14:30, 20 December 2019 (UTC)
Full stop is there after the flerion. The design was copied from the Currency symbols navbox, you can see the names by looking at the popup tooltip or link preview. However it could be altered to have text instead, or more likely both text and symbols. I still feel it would be good to get rid of the sidebar, on several articles it is serioulsy interfering with legibility because it forces the images out of alignment with text, also it seems that directions to other pages should be in navboxes.Spitzak (talk) 18:18, 20 December 2019 (UTC)

Broken barEdit

In your edit to vertical bar, you say that ⇧ Shift+\ produces a solid vertical bar even though the engraving has a broken bar. I suspect that this behaviour is OS dependent. So maybe best you qualify your caption with a note to say which OS? (I have UK extended, not US-int). Your call. --John Maynard Friedman (talk) 11:32, 16 February 2020 (UTC)