7 ms·

Any self-respecting Ctrl+F should match "ä" when the user searches for "a." Chrome and Firefox do.

karatinversion 6y ago
On my firefox (68.9.0esr), a Ctrl+F for "The German character a" finds no results. Also, as a Finnish user, I would not be impressed by a search for "talli" (stables) matching "tälli" (blow), or "länteen" (westwards) matching "lanteen" ('of the hip').
- tom_mellior 6y ago
  > On my firefox (68.9.0esr), a Ctrl+F for "The German character a" finds no results. On mine (77.0.1) it finds the OP's "The German character ä" as well as yours. Conversely, searching for "The German character ä" finds the OP's original and your "a" version. There is a "match diacritics" button for enabling/disabling this behavior.
- earthboundkid 6y ago
  "Should match" above was too strong. "Should match for users with locale set to English" is right though. In English, theoretically you should write "café" and "résumé" but practically speaking, it doesn't matter and no one cares if you omit the accents. In the US, there's starting to be more push from people with ñ in their name to get support for the correct letter, but most government systems have zero support for anything but ASCII all capitals (sorry McWhoever).
- kergonath 6y ago
  I think it depends on the context. I need the search-and-replace dialog in my text editor to be strict about it, whereas I would find it weird if my web browser would not treat a, à, â, and ä the same way. After all, in the languages I speak they are all the same character, just with different accents. This is of course also language-dependent.
- iggldiggl 6y ago
  Firefox only gained that ability very recently in FF73 (https://bugzilla.mozilla.org/show_bug.cgi?id=202251 https://bugzilla.mozilla.org/show_bug.cgi?id=202251), hence it's not yet in the current ESR. It does seem to have a toggle for turning it on/off, though. Normalisation and - except for the soft-hyphen - ignoring of ignorable whitespace characters (ZWNJ, ZWJ, WJ etc.) on the other hand are still missing in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=640856 https://bugzilla.mozilla.org/show_bug.cgi?id=640856).
- scbrg 6y ago
  In contrast, as a Swedish user, I'm spectacularly impressed when, say, a flight or train booking site lets me search for Goteborg rather than Göteborg. Because otherwise, you know, I probably can't get the fuck home from wherever I happen to be with whatever keyboard the particular machine I happen to be using has. The number of times, in actual real life, that the inconvenience of the ambiguity outweighs the convenience of the overlap are not many. YLMV.
  - cyxxon 6y ago
    I would assume that sites like this know these words as synonyms and don't simply do a lax string matching, because in this specific case "Gothenburg" would probably also work - it did when I was planning a route through Sweden with a German app that defaults to local spellings in foreign countries.
    - HelloNurse 6y ago
      Flight and train booking sites need to support search for a very small set of place names: if they care about selling tickets they can list a synonym list for each destination, sidestepping language and spelling norms. Fuzzy completion in search forms as one types, like e.g. in Google Maps, is also effective.
binrec 6y ago
Chrome's Ctrl+F behavior is damned annoying for handling linguistic data. When I search for ʰ (aspiration), I don't want h (the letter, which appears in some of the column headers and most of the notes entries) - conflating the two makes searching for ʰ practically worthless. If I couldn't turn off "ASCII characters match everything that looks vaguely like them" in Google Sheets (i.e. enable regex search), I wouldn't use Google Sheets. ...and now that I've complained about it I notice that there are extensions to enable regex search in the browser itself, nice
corty 6y ago
That is insufficient and wrong. "Apfel" should not match "Äpfel" in a search, because those are different words, one is the singular, the other the plural of "apple". However, "Aepfel" should match "Äpfel", since those are the same word, the former is an accepted replacement form. Similarly, "ss" and "sz" (very rare) should match "ß" and vice versa, so "Strasse" is the same as "Strasze" and "Straße". Of course all of this is locale-dependent and it might be acceptable for ease of use to match "ä" to "a" for international users. But not in a german locale. Proper I18N is very hard, and supporting Unicode is just a first step. Converting text between lower/upper/title-case can only be done knowing at least the locale of the text, and in rare cases a case-folding-roundtrip can even change the meaning of the text, so you will have to be able to speak the language.
- tom_mellior 6y ago
  > Similarly, "ss" and "sz" (very rare) should match "ß" and vice versa, so "Strasse" is the same as "Strasze" and "Straße". This is unworkable, since "Busse" (several autobuses) should not match "Buße" (repentance). But "Busse" (incorrect spelling of "Buße" due to character set limitations/Swiss German spelling I believe) should match "Buße" by your argument. Anyway, modern Firefox lets you choose whether to match "Apfel" against "Äpfel".
  - corty 6y ago
    You are right in that my argument is somewhat incomplete, one could be stricter and not match "Buße" when searching for "Busse" because that would be a somewhat uncommon almost-misspelling in German German. But: "Busse" is not a always incorrect spelling, it's just an "emergency" one, if you really can't use "ß" for some reason. One example is allcaps text, here "BUSSE" and "BUSSE" are not distinguishable, although they have different meanings. Also, there is Swiss German, where replacing ß with ss is the normal form and not at all "accepted in an emergency" like in German German: https://www.galaxus.de/de/page/schweizerhochdeutsch-fuer-anfaenger-deutsche-warum-wir-so-komisch-schreiben-10690 https://www.galaxus.de/de/page/schweizerhochdeutsch-fuer-anf... Incidentially this is one of the instances where you really have to know the language and the context to be able to do a lowercase -> uppercase -> lowercase roundtrip, otherwise you might screw up with "Buße -> BUSSE -> Busse", changing the meaning. Or not, if the current locale is de_CH instead of de_DE. Together, since very often search will be case-insensitive, I think that while you may be correct, being as strict as to not match here would not be what the user would expect. Yes, again, I18N is hard and sometimes it is impossible to do correctly for a machine.
hibbelig 6y ago
I was talking about that Ctrl+F should match ä (the single character) when the user searches for ä (the letter a plus the combining something mark). And vice versa. There is only one key ä on the keyboard, the user probably doesn't have a choice whether that enters the single character version or the two-character version...
- zzo38computer 6y ago
  In case insensitive mode, it should match. In case sensitive mode, I think that I would prefer it to not match.
  - hibbelig 6y ago
    This is surprising, because we aren't talking about searching for ä and matching Ä or vice versa...
enriquto 6y ago
> Any self-respecting Ctrl+F should match "ä" when the user searches for "a." Chrome and Firefox do. Why? That is horrific! They are different letters. Why would you ever need that?
- scbrg 6y ago
  Speaking as someone whose native language has not one, but three of those weird letters, I would need it because it makes searching about a billion times easier. There's plenty of situations where typing my native language's characters is inconvenient for a multitude of reasons, and any particular document is not likely to hold so many individual words dissimilar only by using those particular different letters that the inconvenience of the ambiguity is going to outweigh the convenience of not having to convince my current device to type, say, an ä.
  - enriquto 6y ago
    Would you also match it with α? Notice that "a" and "α" are always completely interchangeable, as opposed to "a" and "ä". What about their uppercase versions (which are visually identical)? Or all similarly-looking letters between Latin, Greek, and Cyrillic alphabets? And what about letters that are almost identical but have very different meanings like "w" and "ω"; would you match them ?
    - scbrg 6y ago
      > Would you also match it with α? I have no idea. I don't speak Greek, and I am not familiar enough with its alphabet. The question, I suppose, is if there's a reasonable/intuitive enough mapping between the Greek and the Latin alphabet that it would be possible to search for Greek words using a non Greek keyboard. If yes, then I suppose my answer would also be yes - but I'm happy to be corrected by someone who is actually speaks Greek. My point is that when it comes to things like searching, usefulness trumps purity. I search because I want to find shit. Not because I want to get perfect feedback on linguistic details from my software.
      - 6y ago
chx 6y ago
I was working on the remove diacritics feature of Drupal this weekend so I am quite fresh with these affairs. "Any self-respecting" -- this is very, very hard. If you are Danish, your keyboard most likely has a way to enter Ø and you would expect Ø and O to be handled as two different letters. However, if an English article mentions the Øresund bridge, it's not unreasonable to expect a search on Oresund to match it. Or, in Hungarian, "kor" means period or age, "kór" means disease and "kör" means circle... but searching for "kor" in Chrome finds all of them. And Unicode won't save you: Ø does not have decomposition rules but ó and ö both do. So the common practice of decomposing - removing marks - recomposing route can either be too little or too much. The upcoming solution for Drupal will allow users to edit remove diacritics rules per language, no other way to do it. This is Libreoffice taking that path, I know Firefox does the same: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-3&id=18bc169b4727744f35227532078cbf7c9558bc9a https://cgit.freedesktop.org/libreoffice/core/commit/?h=libr... see the icu::Transliterator::createInstance("NFD; [:M:] Remove; NFC", part.
- corty 6y ago
  My ideal (but no one has implemented this yet) search would have a slider for strict/lax. In strict mode, only equivalent forms would match, so composed and decomposed would match as per unicode rules, but nothing else. As you get laxer, you obey locale-specific replacements like ö -> oe in German or å -> aa in Danish. Even more lax one could have homoglyphs match, so latin a would match kyrillic а. Then maybe α matches a and β matches b and ß, and of course C matches ℂ and weirdness like that. That already sounds like a few years of research to get it working world-wide. In the last stage, a full DWIM-AI would do the matches. ;)
  - mcswell 6y ago
    Some of this (Latin and Cyrillic A/a, for example) is relevant to e.g. Internationalized Domain Name issues (https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack). I once worked on what we called DYM tools (for "Did You Mean"). The goal was to assist native English speakers who were learning a second language find words they heard, in that language's electronic dictionary. We knew, for example, that native speakers of English have difficulty distinguishing the dental and retroflex consonants of Hindi, so the DYM allowed mismatches of those. A perfect spelling was at the top of the list returned from the dictionary, while a misspelling--such as writing a dental for a retroflex--resulted in the mismatched word being a little lower in the list. We tailored our DYMs for particular target languages (and always for native speakers of English). As you say, getting something like this to work for multiple languages at the same time would be difficult.
SomeHacker44 6y ago
My Exchange server always finds my friend when I search for "Kivanc" even though the "i" and the "c" are Turkish letters without a dot and with a squiggle respectively. However, I cannot get it to find my friend Nikolay when I type the whole thing, as it doesn't match the final Cyrillic letter with my "y". I would say, in general, string matching leaves a lot to be desired, especially when I don't know how to actually type most of the letters of my colleagues's and friends's names. (It's easier on Mac than Windows 10 though - I can't figure out a dang thing for Windows 10 that is not English.)
- lokedhs 6y ago
  If your Russian friend's name is Николай, then you might try to type it as "j", "i" or "ij". I only studied Russian for a short while, but й sounds more like "ij".
  - SomeHacker44 6y ago
    Very nice, thank you! Replacing the "backwards N with hacek" (not sure what the letter is called, sorry) with "i", "iy" or "j" all find him. Funny that his preferred romanization with just a "y" doesn't.
zzo38computer 6y ago
My own opinion is that in case-sensitive mode, writing "a" should not found the accented "a" unless it is in decomposed representation (and even then, only if you are searching for "a" itself, since if you follow it by another letter, then it will no longer match since the combining accent mark intervenes), but never matches a precomposed accented "a". In case-insensitive mode, the behaviour should be locale-dependent and configurable by the user.
alkonaut 6y ago
In Swedish I always want e to match é, and I would never want a to match ä. é is just a different accent of e, not a different character in the alphabet. ä is a completely different character in my alphabet. Similarly ö is a completely different character in my alphabet and should not be considered equal to o, if the text is Swedish. For someone in the US or France, the ö or ë probably is just a pronounciation diacritic as in Raphaël or Cooöperation. Of course an American doing Ctrl+F on a website (Likely New Yorker!) would want to find "Coöperation" when searching for "Cooperation". Even weirder: when I go to the New Yorker and search for Cooperation I want to find "Coöperation" too! So this is highly context dependent. Ideally I want collation/comparison to depend on the content of the page, not my browser/OS language.
- zzo38computer 6y ago
  Yes, that is correct. HTML can declare languages (which are also useful for automatically selecting fonts), so that should be used for searching, too, in addition to font selection, indexing, etc. Another idea would be to do that in Swedish text, "é" will always be represented in decomposed form, while "ä" will always be represented in precomposed form, so that you can tell the difference.
  - sbierwagen 6y ago
    What do you do on a page that's mostly English, but contains a single Swedish quote?
    - zzo38computer 6y ago
      I suppose that you can write: <blockquote lang="sv">...</blockquote>
  - anoncake 6y ago
    Making search work differently depending on the specified language just makes it unpredictable since not everything is marked up correctly.
wl 6y ago
I sometimes work with transliterations of cuneiform. I don't want s to match š, h to match ḫ, g to match g̃, r to match ř, or any accented vowels matching any differently accented or unaccented vowels. They mean drastically different things. If you're going to have a "smart" search that decides to mesh these together, the option to turn off the "smartness" should be right there.
Avamander 6y ago
I despise this behaviour because it has hindered my work so many times. No, just no.

On my firefox (68.9.0esr), a Ctrl+F for "The German character a" finds no results. Also, as a Finnish user, I would not be impressed by a search for "talli" (stables) matching "tälli" (blow), or "länteen" (westwards) matching "lanteen" ('of the hip').

tom_mellior 6y ago
> On my firefox (68.9.0esr), a Ctrl+F for "The German character a" finds no results. On mine (77.0.1) it finds the OP's "The German character ä" as well as yours. Conversely, searching for "The German character ä" finds the OP's original and your "a" version. There is a "match diacritics" button for enabling/disabling this behavior.
earthboundkid 6y ago
"Should match" above was too strong. "Should match for users with locale set to English" is right though. In English, theoretically you should write "café" and "résumé" but practically speaking, it doesn't matter and no one cares if you omit the accents. In the US, there's starting to be more push from people with ñ in their name to get support for the correct letter, but most government systems have zero support for anything but ASCII all capitals (sorry McWhoever).
kergonath 6y ago
I think it depends on the context. I need the search-and-replace dialog in my text editor to be strict about it, whereas I would find it weird if my web browser would not treat a, à, â, and ä the same way. After all, in the languages I speak they are all the same character, just with different accents. This is of course also language-dependent.
iggldiggl 6y ago
Firefox only gained that ability very recently in FF73 (https://bugzilla.mozilla.org/show_bug.cgi?id=202251 https://bugzilla.mozilla.org/show_bug.cgi?id=202251), hence it's not yet in the current ESR. It does seem to have a toggle for turning it on/off, though. Normalisation and - except for the soft-hyphen - ignoring of ignorable whitespace characters (ZWNJ, ZWJ, WJ etc.) on the other hand are still missing in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=640856 https://bugzilla.mozilla.org/show_bug.cgi?id=640856).
scbrg 6y ago
In contrast, as a Swedish user, I'm spectacularly impressed when, say, a flight or train booking site lets me search for Goteborg rather than Göteborg. Because otherwise, you know, I probably can't get the fuck home from wherever I happen to be with whatever keyboard the particular machine I happen to be using has. The number of times, in actual real life, that the inconvenience of the ambiguity outweighs the convenience of the overlap are not many. YLMV.
- cyxxon 6y ago
  I would assume that sites like this know these words as synonyms and don't simply do a lax string matching, because in this specific case "Gothenburg" would probably also work - it did when I was planning a route through Sweden with a German app that defaults to local spellings in foreign countries.
  - HelloNurse 6y ago
    Flight and train booking sites need to support search for a very small set of place names: if they care about selling tickets they can list a synonym list for each destination, sidestepping language and spelling norms. Fuzzy completion in search forms as one types, like e.g. in Google Maps, is also effective.

binrec 6y ago

Chrome's Ctrl+F behavior is damned annoying for handling linguistic data. When I search for ʰ (aspiration), I don't want h (the letter, which appears in some of the column headers and most of the notes entries) - conflating the two makes searching for ʰ practically worthless. If I couldn't turn off "ASCII characters match everything that looks vaguely like them" in Google Sheets (i.e. enable regex search), I wouldn't use Google Sheets. ...and now that I've complained about it I notice that there are extensions to enable regex search in the browser itself, nice

corty 6y ago

That is insufficient and wrong. "Apfel" should not match "Äpfel" in a search, because those are different words, one is the singular, the other the plural of "apple". However, "Aepfel" should match "Äpfel", since those are the same word, the former is an accepted replacement form. Similarly, "ss" and "sz" (very rare) should match "ß" and vice versa, so "Strasse" is the same as "Strasze" and "Straße". Of course all of this is locale-dependent and it might be acceptable for ease of use to match "ä" to "a" for international users. But not in a german locale. Proper I18N is very hard, and supporting Unicode is just a first step. Converting text between lower/upper/title-case can only be done knowing at least the locale of the text, and in rare cases a case-folding-roundtrip can even change the meaning of the text, so you will have to be able to speak the language.

tom_mellior 6y ago
> Similarly, "ss" and "sz" (very rare) should match "ß" and vice versa, so "Strasse" is the same as "Strasze" and "Straße". This is unworkable, since "Busse" (several autobuses) should not match "Buße" (repentance). But "Busse" (incorrect spelling of "Buße" due to character set limitations/Swiss German spelling I believe) should match "Buße" by your argument. Anyway, modern Firefox lets you choose whether to match "Apfel" against "Äpfel".
- corty 6y ago
  You are right in that my argument is somewhat incomplete, one could be stricter and not match "Buße" when searching for "Busse" because that would be a somewhat uncommon almost-misspelling in German German. But: "Busse" is not a always incorrect spelling, it's just an "emergency" one, if you really can't use "ß" for some reason. One example is allcaps text, here "BUSSE" and "BUSSE" are not distinguishable, although they have different meanings. Also, there is Swiss German, where replacing ß with ss is the normal form and not at all "accepted in an emergency" like in German German: https://www.galaxus.de/de/page/schweizerhochdeutsch-fuer-anfaenger-deutsche-warum-wir-so-komisch-schreiben-10690 https://www.galaxus.de/de/page/schweizerhochdeutsch-fuer-anf... Incidentially this is one of the instances where you really have to know the language and the context to be able to do a lowercase -> uppercase -> lowercase roundtrip, otherwise you might screw up with "Buße -> BUSSE -> Busse", changing the meaning. Or not, if the current locale is de_CH instead of de_DE. Together, since very often search will be case-insensitive, I think that while you may be correct, being as strict as to not match here would not be what the user would expect. Yes, again, I18N is hard and sometimes it is impossible to do correctly for a machine.

hibbelig 6y ago

I was talking about that Ctrl+F should match ä (the single character) when the user searches for ä (the letter a plus the combining something mark). And vice versa. There is only one key ä on the keyboard, the user probably doesn't have a choice whether that enters the single character version or the two-character version...

zzo38computer 6y ago
In case insensitive mode, it should match. In case sensitive mode, I think that I would prefer it to not match.
- hibbelig 6y ago
  This is surprising, because we aren't talking about searching for ä and matching Ä or vice versa...

enriquto 6y ago

> Any self-respecting Ctrl+F should match "ä" when the user searches for "a." Chrome and Firefox do. Why? That is horrific! They are different letters. Why would you ever need that?

scbrg 6y ago
Speaking as someone whose native language has not one, but three of those weird letters, I would need it because it makes searching about a billion times easier. There's plenty of situations where typing my native language's characters is inconvenient for a multitude of reasons, and any particular document is not likely to hold so many individual words dissimilar only by using those particular different letters that the inconvenience of the ambiguity is going to outweigh the convenience of not having to convince my current device to type, say, an ä.
- enriquto 6y ago
  Would you also match it with α? Notice that "a" and "α" are always completely interchangeable, as opposed to "a" and "ä". What about their uppercase versions (which are visually identical)? Or all similarly-looking letters between Latin, Greek, and Cyrillic alphabets? And what about letters that are almost identical but have very different meanings like "w" and "ω"; would you match them ?
  - scbrg 6y ago
    > Would you also match it with α? I have no idea. I don't speak Greek, and I am not familiar enough with its alphabet. The question, I suppose, is if there's a reasonable/intuitive enough mapping between the Greek and the Latin alphabet that it would be possible to search for Greek words using a non Greek keyboard. If yes, then I suppose my answer would also be yes - but I'm happy to be corrected by someone who is actually speaks Greek. My point is that when it comes to things like searching, usefulness trumps purity. I search because I want to find shit. Not because I want to get perfect feedback on linguistic details from my software.
    - 6y ago

chx 6y ago

I was working on the remove diacritics feature of Drupal this weekend so I am quite fresh with these affairs. "Any self-respecting" -- this is very, very hard. If you are Danish, your keyboard most likely has a way to enter Ø and you would expect Ø and O to be handled as two different letters. However, if an English article mentions the Øresund bridge, it's not unreasonable to expect a search on Oresund to match it. Or, in Hungarian, "kor" means period or age, "kór" means disease and "kör" means circle... but searching for "kor" in Chrome finds all of them. And Unicode won't save you: Ø does not have decomposition rules but ó and ö both do. So the common practice of decomposing - removing marks - recomposing route can either be too little or too much. The upcoming solution for Drupal will allow users to edit remove diacritics rules per language, no other way to do it. This is Libreoffice taking that path, I know Firefox does the same: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-3&id=18bc169b4727744f35227532078cbf7c9558bc9a https://cgit.freedesktop.org/libreoffice/core/commit/?h=libr... see the icu::Transliterator::createInstance("NFD; [:M:] Remove; NFC", part.

corty 6y ago
My ideal (but no one has implemented this yet) search would have a slider for strict/lax. In strict mode, only equivalent forms would match, so composed and decomposed would match as per unicode rules, but nothing else. As you get laxer, you obey locale-specific replacements like ö -> oe in German or å -> aa in Danish. Even more lax one could have homoglyphs match, so latin a would match kyrillic а. Then maybe α matches a and β matches b and ß, and of course C matches ℂ and weirdness like that. That already sounds like a few years of research to get it working world-wide. In the last stage, a full DWIM-AI would do the matches. ;)
- mcswell 6y ago
  Some of this (Latin and Cyrillic A/a, for example) is relevant to e.g. Internationalized Domain Name issues (https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack). I once worked on what we called DYM tools (for "Did You Mean"). The goal was to assist native English speakers who were learning a second language find words they heard, in that language's electronic dictionary. We knew, for example, that native speakers of English have difficulty distinguishing the dental and retroflex consonants of Hindi, so the DYM allowed mismatches of those. A perfect spelling was at the top of the list returned from the dictionary, while a misspelling--such as writing a dental for a retroflex--resulted in the mismatched word being a little lower in the list. We tailored our DYMs for particular target languages (and always for native speakers of English). As you say, getting something like this to work for multiple languages at the same time would be difficult.

SomeHacker44 6y ago

My Exchange server always finds my friend when I search for "Kivanc" even though the "i" and the "c" are Turkish letters without a dot and with a squiggle respectively. However, I cannot get it to find my friend Nikolay when I type the whole thing, as it doesn't match the final Cyrillic letter with my "y". I would say, in general, string matching leaves a lot to be desired, especially when I don't know how to actually type most of the letters of my colleagues's and friends's names. (It's easier on Mac than Windows 10 though - I can't figure out a dang thing for Windows 10 that is not English.)

lokedhs 6y ago
If your Russian friend's name is Николай, then you might try to type it as "j", "i" or "ij". I only studied Russian for a short while, but й sounds more like "ij".
- SomeHacker44 6y ago
  Very nice, thank you! Replacing the "backwards N with hacek" (not sure what the letter is called, sorry) with "i", "iy" or "j" all find him. Funny that his preferred romanization with just a "y" doesn't.

zzo38computer 6y ago

My own opinion is that in case-sensitive mode, writing "a" should not found the accented "a" unless it is in decomposed representation (and even then, only if you are searching for "a" itself, since if you follow it by another letter, then it will no longer match since the combining accent mark intervenes), but never matches a precomposed accented "a". In case-insensitive mode, the behaviour should be locale-dependent and configurable by the user.

alkonaut 6y ago

In Swedish I always want e to match é, and I would never want a to match ä. é is just a different accent of e, not a different character in the alphabet. ä is a completely different character in my alphabet. Similarly ö is a completely different character in my alphabet and should not be considered equal to o, if the text is Swedish. For someone in the US or France, the ö or ë probably is just a pronounciation diacritic as in Raphaël or Cooöperation. Of course an American doing Ctrl+F on a website (Likely New Yorker!) would want to find "Coöperation" when searching for "Cooperation". Even weirder: when I go to the New Yorker and search for Cooperation I want to find "Coöperation" too! So this is highly context dependent. Ideally I want collation/comparison to depend on the content of the page, not my browser/OS language.

zzo38computer 6y ago
Yes, that is correct. HTML can declare languages (which are also useful for automatically selecting fonts), so that should be used for searching, too, in addition to font selection, indexing, etc. Another idea would be to do that in Swedish text, "é" will always be represented in decomposed form, while "ä" will always be represented in precomposed form, so that you can tell the difference.
- sbierwagen 6y ago
  What do you do on a page that's mostly English, but contains a single Swedish quote?
  - zzo38computer 6y ago
    I suppose that you can write: <blockquote lang="sv">...</blockquote>
- anoncake 6y ago
  Making search work differently depending on the specified language just makes it unpredictable since not everything is marked up correctly.

wl 6y ago

I sometimes work with transliterations of cuneiform. I don't want s to match š, h to match ḫ, g to match g̃, r to match ř, or any accented vowels matching any differently accented or unaccented vowels. They mean drastically different things. If you're going to have a "smart" search that decides to mesh these together, the option to turn off the "smartness" should be right there.

Avamander 6y ago

I despise this behaviour because it has hindered my work so many times. No, just no.