Chrome’s find option, like every search coming from a good home, does something clever with accented characters – it normalizes them:

No matter whether you search with a proper accented character, or with its basic Latin equivalent, all the same stuff matches: The “ø” letter is treated the same as “o” both in the input field, and then in the search itself.

Yet, Chrome’s tab search inexplicably doesn’t do that, which confused me when working on a post about diacritics earlier this week. Here, it should match all four open tabs:

Tab search was introduced years ago; the Occam’s Razor says this isn’t a recent bug, but that the feature has always behaved like this. I filed the bug, but even if it gets fixed quickly, I think this doesn’t reflect well on Chrome’s team. If the right code already exists for ⌘F, why not reuse it? If it cannot be reused, why not repurpose at least its unit tests or the QA process to make sure this doesn’t fall through the cracks? Normalization should be treated as a core property of any search, rather than an optional “nice to have.”

But, Marcin, didn’t you just invalidate your assertion that diacritics actually matter? After all, wouldn’t you input “nestlé” instead of “nestle” if they did?

To this, I have a few answers:

• Input is not output. This is no different than autocorrect, autocomplete, or other IME helpers.
• The very fact that on many keyboards accented characters are hard to input is itself a sign of anglo-centrism of companies that made early typewriters (Remington, which established a lot of European layouts like QWERTZ and AZERTY, employed a person who bragged he didn’t actually speak any languages in a “how hard could it be” way) and then most microcomputers.
• There is this really interesting rule, also known as Postel’s Law: “be conservative in what you output, but liberal in what you accept as input.” It’s not universally applicable – sometimes it’s better to teach the user to be more explicit if it benefits them in the longer run – but it feels appropriate to me here.

Why does it matter specifically for the ⌘F and the tab search experience? I have this personal theory: the simplest the search, the more the users will blame themselves if it doesn’t work, and assume the tab or the string just isn’t there, rather than rewrite their query. That’s what happened to me. I assumed that the tab wasn’t open and tried to get to it again, wasting time and effort.

The rule might be universally true for any UI surface – the tighter it gets, the less likely we assume it can break. After all, there is a manual for a typewriter, but there isn’t one for the pencil! And these UIs do feel positively basic; they are small windows with basically one input field and an immediate as-you-type reaction.

The iOS 26 update introduced a bug in the Czech keyboard. Instead of the customary háček (ǍǎĚěǦǧǏǐǑǒǓǔY̌y̌) in the bottom row, another key was duplicated, removing access to the accent character (or, a diacritic) very popular in that language.

Here is the before and after of this situation:

Ordinarily, this can be frustrating but not insurmountable; you can always copy/​paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones.

The Register reported on this on April 12, and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update.

This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery.

First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting.

Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “dead keys” that either stand alone, or get combined with the previous letter if that makes sense.

This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way.

Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples.

But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote:

Stick with the 7-bit ASCII subset. You will never go wrong.

7-bit ASCII basically means “26 Western letters and nothing else.”

I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this:

Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis. Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not.

If you don’t have a favourite diacritic, you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.)

If you’re interested, here is David J. Ross’s 22-minute talk about getting to love diacritics from the perspective of a type designer. It’s filled with craft and playfulness:

My favourite accent is, obviously, ogonek. Just looking at Adam Twardoch’s guide on how it should be drawn fills my heart with joy:

An entertaining 9-minute video by Shloop that starts with a common mistake of typing in an English mode on a Korean keyboard, but then goes through a bunch of other fun and light input internationalization stories:

This is the page for non-English programming languages that is shown at some point. Quite a bit of stuff in there.

Oh, also, in Polish (my native tongue), spitting is “tfu.”

A funny 12-minute video by Chris Spargo about why traffic signs in the world are standardized only to some extent. This was interesting to me generally in the context of Europe being more iconographic, and America being more “word-y” in their sign design, which extends to devices, keyboards, and (presumably?) software.

The story why [the old STOP sign] got replaced by the American version is also the story why the rest of our signs still look different, and why they probably always will.

I have recently been on a bit of a Japan kick, and someone on social sent me this 2018 article from Clyde Mandelin about translating Japanese videogames:

There’s a common assumption that when you translate something from English into another language, there shouldn’t be any English left when you’re done. Otherwise it would be an incomplete translation, right? And you’d feel like you got cheated out of the money you spent on translation, right?

If you’re translating into Japanese, then that assumption is wrong. English makes up a significant portion of the Japanese language today, and on top of that, English has been a major part of Japanese video games since the very beginning.

I have been thinking a lot about translation ever since in the 1990s, both Windows and Mac OS have been translated to Polish, and while Windows felt okay, people at Apple used more “proper,” but often strangely archaic words for the Mac OS translation that were absolutely readable, but made the Mac felt a bit… I don’t know… medieval? (I saved both of the translations and put them up online long ago. They are still online.)

It is so hard to explain unless someone knows both languages in question, but so important to understand all these little nuances to get it right.

In the world of typing, for example, right-to-left writing systems are not just “going the other way,” but also have to accomodate LTR snippets. Similarly, it’s perfectly fine in Japanese to see Western words – not just next to Japanese writing, but sometimes inside it. For those working on these, it must be annoying that you already have to do more work with more complex writing, encodings, and stuff (most languages to me feel more complicated than English) – but now you also have to include entry points for other writing systems.

The issues of translation are fascinating to me. Please send more if you see them.