Content deleted Content added
→Decimal input (Windows): Workarounds there are plenty; but why are they needed? |
→Where?: new section |
||
| (41 intermediate revisions by 9 users not shown) | |||
Line 1:
{{WikiProject banner shell|class=C|
{{WikiProject Writing systems |importance=Low}}
}}
== Windows EnableNumKeypad clarification ==
Line 149 ⟶ 153:
:::[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 02:19, 13 September 2020 (UTC)
== Decimal input (Windows) Part 2 ==
::::I bow to your more extensive knowledge and trust that you will clarify the article accordingly.
::::You say that the reference to CP1252 is not needed. So why is it that a user with Japanese layout gets something other than {{char|£}} after typing Alt+0163? Does that not disprove your rule? 163<sub>10</sub> is certainly the correct Unicode value for the codepoint but Windows is delivering something from the 163rd slot in its Japanese code page which is definitely not {{char|£}}.--[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 16:33, 13 September 2020 (UTC)
Line 156 ⟶ 161:
:::::{{re|Ozaru}} Have you considered using a [[script language]]? I have an [[Autohotkey]] script that runs by default; I use it for [[em dash]]es among many other things. The Autohotkey script to make {{keypress|Cntl|F}} produce a {{char|£}} would be just {{code|^f::£}}. [[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 00:37, 15 September 2020 (UTC)
::::::There are plenty of ''workarounds'' (e.g. {{key press|Windows}}+{{key press|Space}} to switch to UK/US, {{key press|Alt}}+{{key press|0}}{{key press|1}}{{key press|6}}{{key press|3}} then {{key press|Windows}}+{{key press|Shift}}+{{key press|Space}} to switch back; or phonetically entering ぽんど into the [[Input method|IME]] and hitting {{key press|Space}} one or more times to select the right symbol, or Autohotkey as you say). The issue is more that despite the best intentions of moving from 8-bit [[SBCS]] to 16-bit [[DBCS]] and standardizing with Unicode while computers themselves become 32 and 64-bit... it still seems impossible to break free from the 8-bit codepage legacy, which I find incredible. It's amazing (not to say inconvenient) that even now, [[Visual Basic for Applications|VBA]] Editor doesn't support Unicode, [[Microsoft Excel|Excel]] can't save Unicode CSV files, and basic Windows 10 dialogs etc. don't have a simple, in-built way for Unicode input. So much for [[I18N]]. [[User:Ozaru|Ozaru]] ([[User talk:Ozaru|talk]]) 05:55, 15 September 2020 (UTC)
:::::::Couldn't put it better myself (I didn't!). As already noted, the £ glyph is just a random example, the issue is widespread. Which takes me back to my first challenge to the section. It is worse than misleading while it remains unqualified. --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 16:05, 15 September 2020 (UTC)
:::::"... while <u>it</u> remains unqualified." Sorry, what is "it"? My revised wording begins, "Some programs running in [[Microsoft Windows]], including [[Microsoft Word|Word]] and [[Wordpad]] ...". Isn't that sufficient qualification? I don't see a need, here, to mention that whether one can produce {{char|£}}, {{char|Ð}}, etc. on [[Notepad]] or [[Visual Basic for Applications|VBA]] depends on the code page in effect. [[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 19:05, 15 September 2020 (UTC)
::::::"it" = "the text". The text that says that this method works when the real story is "it depends". Setting ever tighter parameters so that we can continue to say that it works is being "[[economical with the truth]]". We need to say that the method doesn't work reliably for keyboard settings outside the Americas, Western Europe, Southern Africa, A&NZ and (former) Western European colonies. IMO. --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 20:07, 15 September 2020 (UTC)
::I think it can be stated this way:
:::In some cases Microsoft extended the [[Altcode]] inputs so that Unicode code points could be typed as decimal numbers.
:::For the numbers 0-256 the user had to type a leading zero (so that the "ANSI" code page was used) and also the ANSI code page had to be set to something that matched the first 256 characters of Unicode for all useful characters ([[CP1252]]).
:::For numbers greater than 256 there were numerous different results, ''depending on the software being used and the version of Windows'':
::::* The number had to be prefixed with a zero to work
::::* At least 4 digits had to be typed (ie leading zero on n <= 999) to work.
::::* The numbers did not work at all (usually producing the character for n modulus 256)
::::* Numbers greater than 65535 might not work even if smaller numbers do.
[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 20:58, 15 September 2020 (UTC)
::::Re Spitzak's four bullet points:
:::::*In Wordpad, Alt+960 and Alt+0960 ''both'' produce a {{char|π}}, which is the correct Unicode character. The high-order zero doesn't matter.
:::::*Same counterexample. Alt+960 works just fine.
:::::*960 ≡ 448 modulo 256, but in Word and Wordpad Alt+448 and Alt+0448 both produce, not {{char|π}}, but the glottal stop {{char|ǀ}}. Modulo 256 has nothing to do with it.
::::::*Peter M Brown edited his own comment to the above text, however his previous version makes mathematical sense: "960 ≡ 192 modulo 256, but in Word and Wordpad Alt+192 produces a {{char|└}}(per CP437) and Alt+0192 produces an {{char|À}} (per Unicode and CP1252). Modulo 256 has nothing to do with it." Basically the number 960 is irrelevant, the only interesting thing in the above statement is whether 448 turns into 448 or 192.[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 19:42, 18 September 2020 (UTC)
:::::*Numbers greater than 62235 ''might'' not work? I've produced two cases of numbers that big that do work (one here and one in the article). Why is Spitzak so suspicious of the others?
::::I agree with {{u|John Maynard Friedman}}, above, that we should not confuse "the numeracy-challenged with incomprehensible talk of modulo 255," assuming that he really means 256. Spitzak evidently disagrees, as he has introduced such considerations into the article. However, [[Unicode input]] is, or should be, entirely concerned with Unicode input, with ways to produce characters when one knows their code points. Modulo 256, applicable to [[Notepad]], outgoing [[Gmail]]s, etc. could be discussed in the [[Alt code]] article, but it is not relevant here, because
:::::*discussion is limited to Word and Wordpad as well as similar programs like [[LibreOffice|LibreOffice writer]], and
:::::*for Unicode input purposes, the only point of knowing about equivalence modulo 256 (if it worked in Word etc.) is that, if one thought the number 666 accursed, one could produce the character {{char|ʚ}} using 154 or 410.
::::[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 01:47, 17 September 2020 (UTC)
::I reverted your change to this talk because your edited version makes absolutely no sense. Nobody is suggesting any possible way that 960 will turn into 448, it will either turn into 960 or 192. Also your suggestion that modulus can go "backwards" and turn 154 into 666 is ludicrous (because 154, 410, 666, 922, 1178, ... are all possible answers and there is no reason to choose one of them, other than the first).
::The non-bmp text I stuck in there because of older text claiming more than 4 digits might not work. I found it doubtful that 9999 is the cutoff and that it was typical Windows stupidity about non-BMP which starts after 65335. It sounds like there is no such cutoff, either with 4 digits or at some point that requires more than 4 digits, so all such text is removed.[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 18:20, 18 September 2020 (UTC)
:::Spizak, there are no circumstances in which you should edit another editor's contribution unless it is a known troll. I strongly advise that you self-revert and apologize. If Peter raises an ANI, I would have to support him. --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 19:29, 18 September 2020 (UTC)
::I'm reminded of the folk song "[[Green Grow the Rushes, O]]". Each verse ends with
:::"One is one and all alone and evermore shall be so."
::One can never turn into two, nor can 960 turn into 192, despite Spizak's claim to the contrary. My claim that he thinks "makes absolutely no sense" is
:::"960 ≡ 448 modulo 256, but in Word and Wordpad Alt+448 and Alt+0448 both produce, not {{char|π}}, but the glottal stop {{char|ǀ}}."
::He evidently did not read, or did not credit, my [https://en.wikipedia.org/w/index.php?title=Talk:Unicode_input&diff=979079891&oldid=979070271 edit summary]:
:::"See [[Modular arithmetic#Examples]]. The numbers on both sides of the ≡ symbol can be greater than the modulus."
::The indicated section in [[Modular arithmetic]] begins:
:::"In modulus 12, one can assert that:
::::<math>38 \equiv 14 \pmod {12}</math>
:::because {{math|38 − 14 {{=}} 24}}, which is a multiple of 12. Another way to express this is to say that both 38 and 14 have the same remainder 2—when divided by 12."
::Likewise 960 ≡ 448 (mod 256) because 960−448 = 512, which is a multiple of 256. Also, 960 and 448 have the same remainder, 192, when divided by 256.
::[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 03:29, 19 September 2020 (UTC)
:::You are talking about all the numbers that are equivalent. I was talking about the [[modulo operator]] which returns the smallest of these numbers. In any case 960 ≡ 192 mod 256, and 960−192 = 768 = 3 × 256, so you have no reason to think 448 is more likely than 192. The weird thing is your example actually shows the correct characters you might get if you type 448 (either 448 or 192) but I still don't understand why you have 960 in that sentence. Just to prove this, lets ask Python what 960 mod 256 is, and make sure no 448 appears:
>>> 960%256
192
[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 18:55, 19 September 2020 (UTC)
::::Of course I'm talking about equivalence. Why do you think I went to the trouble of generating the non-keyboard equivalence symbol {{char|≡}}?
::::I have no reason to think that 448 is more <u>likely</u> than 192? Likelihood is relevant to indeterminate processes. We're doing math, not election forecasting.
::::As you noted, I switched from 192 to 448. I regarded brevity as a virtue and, with 448, I needed only to exhibit the one symbol {{char|ǀ}} rather than both {{char|└}} and {{char|À}}.
::::Why did I use 960? I needed a number greater than 255, so a leading zero would make no difference, as a counterexample to your first and third bullet points. For the second point, it needed to be less than 1000. Finally, I thought it would be nice if it encoded a familiar non-Latin character and {{char|π}}, decimal code point 960, seemed a good choice because of its relevance to geometry.
::::[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 01:16, 20 September 2020 (UTC)
::Sorry to keep this going, but I really think you have some misunderstanding of this, though I cannot figure out exactly what your confusion is, but I am just trying to be helpful and correct it. Basically either mod-256 is applied to the number typed in or it is not. This means that 960 either turns into 960 or 192, and can therefore produce either {{char|π}} or {{char|À}}. And it means that 448 can either turn into 448 or 192, and can therefore produce either {{char|ǀ}} or {{char|À}}. What you have shown is that in Wordpad, the first case (no modulus) applies, for both letters. But neither example has improved "brevity" over the other. And you seem to think that showing that another number that is equivalent to 192 also does not have modulus applied somehow enforces the idea that "modulus has nothing to do with it". Of course modulus has nothing to do with the case that ''modulus is not used''. IMHO a better proof would be to use a number that is ''not'' equivalent (just in case somebody want's to claim that you have only proven that modulus is not applied only to numbers that are equivalent to 192 modulus 256).[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 18:23, 20 September 2020 (UTC)
:::You continue to write of numbers turning into each other. I wrote above that "One can never turn into two, nor can 960 turn into 192, despite Spizak's claim to the contrary." Since you continue to write of numbers turning into each other, you must mean something by this locution, but I find it baffling. Likewise your talk of numbers "having modulus applied". Only someone who understands this concept could "claim that [I] have only proven that modulus is not applied only to numbers that are equivalent to 192 modulus 256". As I do not understand, I could not reply.
:::My statement that "modulus 256 has nothing to do with it" was perhaps too vague. The context was the production of characters using the Alt key in Word or Wordpad; I meant only that, within this context, the character produced does not depend on what characters are equivalent modulo 256 to the number entered.
:::[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 21:05, 20 September 2020 (UTC)
::I am having a very hard time trying to figure out what you are thinking. The words "turns into" means: the user types the number 960, and the software eventually inserts a Unicode character with a certain code point, lets assume that for some reason this code point is 192. The input to this operation is the number 960, and the output is the number 192. I think it is extremely common to say "960 ''turns into'' 192" and am really curious why this term confuses you and how you would state it.
::Using "turns into" your statement is "960 is equivalent to 448 modulus 256, and 448 turns into 448, not 192, therefore modulus has nothing to do with it". What you have shown is that modulus is not applied to 448. And the number 960 is completely irrelevant to this conclusion.
::The other question is why you think using 448 instead of 960 somehow increases "brevity". My best guess is that you think the system might turn 960 into 448 and that you are avoiding difference between ANSI and OEM code pages? But then you correctly indicate that 448 turns into 448, not involving 960 at all, and even correctly identify the code point 448 would turn into if modulus 256 was applied (192, using the character from the ANSI code page). I am really trying to figure out your logic here. Perhaps you could write the "less brevity" version using 960 so I could get some idea of what in the world you are thinking?[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 18:53, 21 September 2020 (UTC)
:::I find this use of "turns into" quite bizarre and I still don't get it. According to you, "The input to this operation [typing a number] is the number 960 and the output is the number 192." No. In Word or Wordpad, the output is the character {{char|π}} which, in Unicode, has a decimal code point of 960. In Notepad or in the Wiki edit box, it's {{char|└}}, which has a decimal code point of 9592.
:::I don't know Python, but I do know Excel. It has a "mod" function of two variables, formatted "mod (a,b)", which, if a and b are positive integers, returns the least nonnegative integer r such that a = nb + r for integral n. Perhaps, by "x turns into y" you mean that y = mod (x,256)? That would fit one of your examples, as 192 = mod (960,256). However, this interpretation doesn't fit your claim that 960 could (depending on what?) turn into 960, since 960 ≠ mod (960,256).
:::As regards brevity, surely it is briefer to display the one character {{char|ǀ}} rather than to display two characters, {{char|└}} and {{char|À}}.
:::Also, you have not explained what it is for a modulus to be "applied". Knowing what it is for paint or fertilizer to be applied does not get me very far.
:::[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 22:22, 21 September 2020 (UTC)
It seems to me that you are both getting bogged down because there are multiple processes at work here and consequently you are talking past each other. You need to agree terminology first.
* In mathematics, we can say that if {{math|1=b=f(a), c=f′(b) and d=f″(e)}}, if follows that {{math|a is some function of e}}. In your case, it is a series of modulo operations by which {{math|a}} may be transformed into {{math|e}}. I ''think'' you are arguing about the significance or otherwise of {{math|b}}, {{math|c}} and {{math|d}}. I suggest you guys resolve this one first.
* In commercial computing, there are multiple co-operating processes.
**The keyboard handler recognises that the Alt key has been pressed and so sends the scan-codes for 9 6 0, duly tagged.
**The next layer decides what to do with that information: the result depends on whether the receiving application is a legacy one like notepad or modern one like Office. In Windows, it also depends on the active code-page because the outcome differs by territory (as our Japanese friend has pointed out).
** The application next does ''two'' things: (a) store what it is programmed to understand as the 'right' answer{{snd}} a binary/hex number{{snd}} in a file and (b) sends that number to the display driver and/or printer. Thus what is displayed ''on this system, at this time'', will be {{char|π}} or {{char|└}} or {{char|À}}{{snd}} but it can be only one.
** If the Windows user sends that file to a Japanese friend or a Mac user, the display/print may differ. [I am conscious here that the context for ''this'' discussion is Unicode input, so substitution of (for example) curly quotes for typewriter quotes probably won't happen, but autocorrect has a habit of barging in where it is not wanted so I'm not taking any bets!).
Does that help in any way or just add to the confusion? --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 14:44, 22 September 2020 (UTC)
== Decimal Input (part 3) ==
Yes, I absolutely agree there is just misunderstanding here, not an argument. I believe Peter Brown has some fundemental error and I really am trying to be helpful in correcting it, though it is very hard to tell exactly what his error is. The basic question is why he started talking about 448, either implying that mod-256 can turn 980 into 448, or that for some reason 448 has fewer possible results of mod-256 than 980, when in fact both of them turn into the exact same number, 192.
I think your math expression is possibly messed up as you use letters in the last one that don't appear in any others, thus it's unrelated. But yes y=f(f'(f"(x))) defines a function that applies f" to x, f' to that result, and f to that result, and could be written as a new function h such that y=h(x).
You are wrong about what happens when a file is sent to Japan. All the software under consideration is storing the resulting unicode code points in the file, not the numbers the user typed, and the file will display the same there.
I'll try to outline my understanding of what happens, and emphasize where I think the confusion might lie.
The user types {{keypress|Alt|9}}{{keypress|6|0|chain=}}. This produces the number 960 which the software will now turn into a character. The user may also type {{keypress|Alt|4}}{{keypress|4|8|chain=}} and produce the number 448 which the software will now turn into a character.
For ''some'' software, the numbers are used directly as the Unicode code point. For 960 this produces U+03C0 which is {{char|π}}. For 448 this produces U+01C0 which is {{char|ǀ}}.
For ''other'' software (ie a different program than the one that used it as a Unicode code point), the numbers have the [[modulo operator]] 256 applied. This turns ''both'' 960 and 448 into 192 (and I'm sorry, but I have always heard this described as "turns into" and have worked in computers for 40 years on both coasts and in England). They both turn into exactly the same number, therefore any further steps are exactly as easy or hard to describe for each of them, there is no advantage of talking about 448 over 960.
There is a further confusion in that 192 is not used as a Unicode code point, but instead it is used to index either the "ANSI" code page or the "OEM" code page.
If the ANSI code page is used, and it is set to [[CP1252]] (which it usually is), then 192 turns into U+00C0 or {{char|À}}. Thus 192, 448, and 960 all turn into {{char|À}} in these programs. Most of CP1252 matches Unicode, including ___location 192, for these locations you can pretty much say the 192 is turned directly into Unicode.
If the "OEM" code page is used (which appears to be the case "in Notepad or in the Wiki edit box") it looks at ___location 192 in [[CP437]] (or some similar page), and gets U+2514, which is {{char|└}}. Thus 192, 448, and 960 all turn into{{char|└}} in these programs.
I would be very interested in what happens if {{keypress|Alt|0}}{{keypress|9|6|0|chain=}}, ie with a zero prefix, is typed "in Notepad or in the Wiki edit box". This may cause 192 to be chosen from the ANSI code page and get {{char|À}}. Or it might cause Unicode to be used.
[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 16:23, 22 September 2020 (UTC)
:"The basic question", according to Spitzak, "is why he started talking about 448". I have answered that. I switched my discussion from 192 to 448 because "with 448, I needed only to exhibit the one symbol {{char|ǀ}} rather than both {{char|└}} and {{char|À}}." I was trying to make things simpler, but clearly I failed.
:I am now retired, but I worked in computers 1972 –2003 and don't recall any talk of numbers turning into each other, which Spitzak seems unable either to avoid or to define. This is unnecessary for our purposes, however, as {{u|John Maynard Friedman}} has provided an excellent statement of the processes under consideration, not once using the troublesome phrase "turns into" or mentioning moduli as being "applied". I suggest that we leave it at that.
:In Notepad, {{keypress|Alt|0}}{{keypress|9|6|0|chain=}} yields {{char|À}}, from the Windows code page. As the section {{section link|Windows_code_page#ANSI_code_page}} notes, these are officially known as "Windows" not "ANSI" code pages. According to [https://web.archive.org/web/20181208141313/https://msdn.microsoft.com/en-us/goglobal/bb964658.aspx#a MSDN], the latter "is nowadays a misnomer that continues to persist in the Windows community." I suggest avoiding misnomers.
:[[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 19:25, 22 September 2020 (UTC)
::"undergoes a transformation operation" is math jargon for 'turns into', if you must be purist about it, The question is made doubly difficult by Microsoft's track record of playing ducks and drakes with standards (aka "embrace and undermine") without us getting picky about choice of words when the meaning is obvious. That is why I'm suggesting that terminological exactitude is critical. --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 19:58, 22 September 2020 (UTC)
:::I'm torn between just letting the discussion die and objecting to being called "picky". After wrestling with the issue, I'm afraid that I come down on the side of protest. "960 turns into 192" cannot be parsed as "960 undergoes a transformation operation 192" unless "transformation" and "192" are in [[apposition]], which is clearly not the intent. My suggestion that it meant 192 = mod (960,256) was apparently incorrect, but it was an honest attempt at making sense of "turns into". To me, the meaning was and is not obvious. So long as I'm not called "picky", I'm content to let it remain obscure. — [[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 02:22, 23 September 2020 (UTC)
::::192 = mod (960,256) is exactly what I meant by "turns into". You take 960, apply the mod-256 operation to it, and you get 192. So the number 960 turns into the number 192. It is possible this terminology is popular in computer science because the input is often not needed after the operation and is discarded, or may even be replaced by writing something like {{code|1=x = mod(x, 256)}} which replaces x with it's value mod 256, actually turning x into a new number.[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 02:36, 23 September 2020 (UTC)
== Direct drawing on a touch screen ==
CJK characters are routinely entered by drawing directly on a touch screen. Meaning that I have seen it being done more than once so it must be routine. {{smiley}}
Does anybody know enough to add a section to that effect? [[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 15:56, 3 August 2023 (UTC)
== alt + x Windows ==
alt + x works also in Notepad 11.2112.32.0 on Windows 10, not sure about previous versions. [[Special:Contributions/213.184.17.126|213.184.17.126]] ([[User talk:213.184.17.126|talk]]) 15:48, 6 September 2023 (UTC)
alt + X does not work on my HP laptop running Windows 11. [[Special:Contributions/136.36.180.215|136.36.180.215]] ([[User talk:136.36.180.215|talk]]) 01:04, 8 September 2024 (UTC)
== Missing: UTF-8 hex input ==
The article doesn't currently mention it, but UTF-8 is the de facto standard for representing Unicode in computer systems. PHP, and perhaps other languages, have built-in ways to specify Unicode characters of any length (including exotic combinations of glyphs and properties) using hexadecimal number literals. Most online Unicode character descriptions include UTF-8 representations. So shouldn't the article reflect this reality, instead of keeping alive the mostly outmoded concept of code points? The most compact way to represent Unicode characters of any byte length greater than one is through UTF-8 hexadecimal. [[User:David spector|David Spector]] ([[User Talk:David spector|talk]]) 17:09, 29 January 2024 (UTC)
:I have not seen any input methods that use UTF-8 code units. Maybe you can use {{tt|\xNN}} for each byte in a string constant in some languages, but this is pretty uncommon.[[User:Spitzak|Spitzak]] ([[User talk:Spitzak|talk]]) 19:04, 29 January 2024 (UTC)
== Where? ==
"Microsoft Windows has provided a Unicode version of the Character Map program, appearing in the consumer edition since XP" Where is this found?[[Special:Contributions/136.36.180.215|136.36.180.215]] ([[User talk:136.36.180.215|talk]]) 01:05, 8 September 2024 (UTC)
| |||