GrygrFlzr

Unfortunately, this also means I'm competing with nearly a hundred different APs in the apartment alone - of which many broadcast in both 2.4GHz and 5GHz - to the point that my Macbook less than a meter away from the router still takes a hot minute to automatically find the AP unless I manually select it.

I have encountered even worse issues digital forms that only accept kanji (Chinese characters) or hiragana (syllabary designed for native Japanese words), the latter of which usually does not support certain voices that katakana supports. Ashley Tisdale, for example, is normally rendered as アシュレイ・ティスデイル (ashurei tisudeiru) - ティ is actually te with a small -i modifier, which does not usually exist with hiragana. Forcibly converted to hiragana, it turns into あしゅれい・てぃでいる - but ぃ is not accepted by the form, even if it exists in UTF-8. Your options are either converting the ティ into ち (chi) or て (te), neither of which are ideal, and may cause mismatches to other systems that properly support the katakana version.

The problem extends further into physical paper forms, where often they provide a very limited amount of boxes for characters, because native Japanese and Chinese names can easily fit within 8 characters. Combine this with the digital systems above and you're bound to have several versions of your name floating around on official documents all mismatching each other.

Some systems that need to print onto physical cards (e.g. getting a 1/3/6 month route pass on your SUICA or PASMO contactless smart cards) are even worse and turn dakuten (diacritics for hiragana/katakana) into their own character. As an example, the character ほ (ho) can be turned into ぼ (bo) using a dakuten, or ぽ (po) using a handakuten. The system will instead render those as two separate characters: ほ゛ and ほ゜ respectively, which cuts down on the number of available characters for the already limited textbox space you're dealing with.

The world is full of presumptions about names even today.

I had to recheck this was indeed an article from 2023, because this part surprised me greatly. To my understanding, es2016 only added Array.prototype.includes, the exponentiation operator (**), and preventing generator functions from being constructed. Even the slowest adopters already had these in 2017. Is the author assuming IE11 support?

As it gets easier and cheaper to run LLM-based bots, I wonder how long this approach will keep working. Devs in mid-to-large companies should have colleagues they can ask directly, but smaller startups might be vulnerable to being artificially swayed towards specific options.