Wikipedia:Reference desk/Archives/Computing/2021 November 24

Computing desk
< November 23 << Oct | November | Dec >> November 25 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


November 24

edit

The 'l' with it

edit

Microsoft news has a story about Camilla Tominey and the Duchess of Sussex at [1]. Capital "I" and small "l" render exactly the same but if one types in a small "l" in front of the "X" instead of a capital "I" the story comes up in Simplified Chinese. Why can't websites differentiate all their characters? 2A00:23A8:4015:F500:6569:7504:D1B9:83A9 (talk) 12:40, 24 November 2021 (UTC)[reply]

What do you mean by "Why can't websites differentiate all their characters". You're discussing the behaviour of one particular website and ultimately only the developers of the website can say why it does some particularly thing. It would be possible for the developers of the website to code it to treat characters that can look alike as the same thing or at least avoid using them so you get an error. But they seem to have chosen not to, probably in part because they figure few people are typing out the characters so it's rarely an issue. Nil Einne (talk) 13:12, 24 November 2021 (UTC)[reply]
On the computer I'm using now there is differentiation on Google Chrome, but on the one I was using earlier there wasn't. Firefox is making the distinction and so is Internet Explorer. Is this something to do with the mechanism by which the individual computer prints out the datastream it receives from the website or maybe the version of the browser which is installed? On the preview of my edit summary there is no differentiation on Chrome, but in the running text in the edit window there is. This does not carry over to Wikipedia pages in "read" mode. Same for Firefox and Internet Explorer. 2A00:23A8:4015:F500:6569:7504:D1B9:83A9 (talk) 13:30, 24 November 2021 (UTC)[reply]

I'm still very confused what your question is. I and l are different characters encoded by different bytes and which probably every single browser that has ever existed is able to differentiate without issue. From the browser's POV, the difference between I and l and I and x or K and l or whatever is more or less the same in the vast majority of contexts. The fact that I and l can look the same in some fonts doesn't affect the browser's ability to differentiate to them, confusing the 2 is simply not an issue for the browser. No matter what the characters look like, and if you use a font like Webdings, they'll probably look quite weird there is no confusing them. If you copy them, you can paste them somewhere else with a different font and you'll see that in all circumstances whatever the character is stays the same. If it's an I, it's always an I. It doesn't randomly switch between an I and an l.

On that note, in many circumstances the browser doesn't know or care what the characters are supposed to represent and in most it doesn't know or care what they look like. On some fonts the characters may look very similar, or the same to a user. This may be the browser's "fault" since it may have specified the font. Or probably more accurately the browser has a default preference for a font where certain characters may look the same. It's often also possible for users to adjust these preferences, and the preference may depend on other things like the OS or what fonts are available so in some way the user is also involved. I think in some cases the font used may relate to some OS setting in which case you could say it's the OS designer's "fault" or the user's if they chose that setting.

Note that browser UI elements including the URL bar cannot generally be influenced by the website so it's not something that's the web designer's fault or related to the website. However text on the website itself may be displayed using a font of the website's choosing so for text of the URL on a website you could say it's the webdesigner's "fault". Although again these can also depend on browser settings which may or may not relate to OS settings so I'm not sure whether it's always fair to say it's the webdesigner's "fault".

In all cases, you could also blame the font designers for designing their font in such a way that the characters either look the same or are hard to distinguish. Frankly if this bothers you such much, I'd suggest you just remove any fonts on your OS where it's an issue. This won't completely prevent the problem since websites and some software and document types can provide their own fonts. Still it should reduce it and hopefully eliminate it on the US elements of all browsers.

Nil Einne (talk) 15:40, 24 November 2021 (UTC)[reply]

I note that, for instance, http://msn.com/en-gb/news/newsbirminghan/joeseph-stalin-downvoted-for-mediocre-dance-routine/ar-AAQy7IX is the exact same story, whereas changing the upper case i to a lower case L actually produces (in, as you say, Chinese) shopping advice for choosing an explosion-proof infra-red camera for use in facilities such as volatile chemical works. So the human-readable part of the address is completely functionless, except as guidance to humans about which story the code links to.
Which is fortunate, since "Birmingham" is misspelled.  Card Zero  (talk) 19:23, 24 November 2021 (UTC)[reply]
The Chinese article is about common problems with explosion-proof infrared cameras. The same article is also found here on the website of sina.com.cn. Apparently, the articles on Microsoft news are indexed by a code that is the last fragment of the URI. What comes before is less relevant; you'll find the article about the Tominey–Markle spat also at https://www.msn.com/en-us/news/fakenews/msn-is-evil/ar-AAQy7IX. A more vexing problem is why font designers do not see fit to give distinct characters distinguishable looks, so that we do not expect Kim Jung Il to be succeeded by Kim Jung III.  --Lambiam 14:11, 26 November 2021 (UTC)[reply]

I don't think the practice of only caring about the unique identifier is particularly uncommon.

It's probably especially common with news sites. E.g. all three of https://www.stuff.co.nz/world/fun/127081564/cutest-cats-in-the-world & https://www.vox.com/22639366/cute-cats-you-just-have-to-see & https://www.nbcnews.com/news/fun/cats-to-make-your-day-rcna4443 lead to arguably more important news stories than actual cute cats. Although I wouldn't recommend using that as a way to trick friends or family except as a joke for those who don't need the stories. For those that do, I expect it's probably generally going to be counter productive.

Other sites where it may be common are probably store sites. E.g. neither of these URLs will lead you to where you can buy New Shepard from Amazon https://www.amazon.com/New-Shepard-spacecraft/dp/B07YD3G568 https://www.amazon.com/New-Shepard-spacecraft/dp/B07MFZXR1B instead they'll lead to a 14TB HD and a 2TB SSD respectively. Likewise this if someone asks you to buy this for their birthday, the URL may lead you to think sure then you click or preview it and may change your mind https://www.thewarehouse.co.nz/p/100-ways-to-improve-your-life-by-/R2779683.html

Nil Einne (talk) 08:08, 29 November 2021 (UTC)[reply]

lead-filled phone cables

edit

[2] Why the heck do phone cables have 3 pounds of lead per foot? I'm imagining so huge trunk with a lot of individual conductors, but still, that's an awful lot of lead. I've used a lot of 100 pair cables (50 copper twisted pairs) that afaik have no lead at all. So I'm puzzled by the idea of cables with so much lead. 2601:648:8202:350:0:0:0:69F6 (talk) 18:13, 24 November 2021 (UTC)[reply]

The news article specifically mentions old cables. Before the introduction of plastic sheathing on telephone cables they were sheathed with lead as it is easily worked and non-porous. The conductors in these cables were often insulated with paper, kept dry by pressurising the cable with dry air to protect against minor leaks. 2A00:23C7:5C40:9D01:55C3:DABB:778D:9C1 (talk) 19:20, 24 November 2021 (UTC)[reply]