Nothing wrong on your end, but also not a simple fix — the web library uses a more sophisticated database that can do accent-insensitive searches automatically.

No ETA here, but this should become more possible after we move Zotero to a new architecture, which we're hoping to do this year or early next year.

@djross3 Zotero should normalize precomposed & decomposed unicode on import (and export) since version 4.0.25.1, January 2015. Are you sure this is happening with pairs of items imported since then?

If it is, that's probably better in a new thread.

@dstillman Is it not possible to use a lookup table to ignore diacritics during searches? For example a lookup table that substitutes any instance of é with e, just during the search, and create a temporary string without any accented characters? Are you saying that the current architecture cannot do any string manipulation of this kind? I am hard pressed to find a programming language that cannot do this, but I don't know what's Zotero's architecture.

This problem bothers me very regularly. Even english speakers have this problem because of exactly what you described.

@emilianoeheyns Thanks for the suggestion.

Wouldn't another option simply have an additional column with the author names without problematic characters when adding an article to the database?

Or even better, simply having the choice to completely ignore accents when saving an article from the web? I personally wouldn't care of not having accents at all. That way the problem is solved at its source.

Huh - I could implement the first option as a plugin, I think, by adding pseudo-fields. These would still need to be saved to a separate database (or startup would become massively slower as the database grows), which has some risk for race conditions, and I would have to add a pseudo-field for every field that would be searchable this way. It'd be a bit of work though.

...when the full range of transliteration options is added (romajization tables are massive)

1. Not implementing this because it would be difficult to implement in the most extreme cases doesn't make sense as an argument to me. If Japanese (and some other languages) can't be supported, then that doesn't mean that all other languages must also wait, including those that would be much simpler to implement.

2. From my perspective (as a linguist) there is a fundamental difference between searching "a" and "á" as the same character and treating Japanese glyphs as variants of romaji. While the latter could also be helpful for searching, it's less transparent and expected. A similar comparison can be made for, say, German umlauts: we should be able to search for "ü" by typing just "u", even though a standard alternative for writing "ü" on a keyboard without umlauts is "ue". If you want to implement both, that's fine. But similarly for "ß" and "ss", that's not so obviously the "same character", as in the case of "ü/u" or "á/a", etc. Letters with obvious diacritics should be searched as if the base form, while anything beyond that would be a bonus but, as you said, much more complicated to implement.

There is also a secondary issue, which is that if you include variant spellings, then it should be possible to look them up either way, which makes it even more complicated (and won't work with the proposed method of a secondary search table with diacritics removed). In that case, "ß" should search for "ss" and "ss" should search for "ß", and for that matter "ü" should search for "u", etc., but that's again going beyond the basic functionality corresponding to the simple "á" and "a" case. I'm not even sure that more complex functionality would be transparent to everyone searching, although in principle it could be useful if, say, you wanted to search for the same author's name whether written in Japanese or transliterated in English/Romaji. A secondary problem, of course, is that there are many different ways of transcribing some languages (this is especially the case with Russian, for example), so it would be too complex to implement fully.

In short, ignoring (during search) the most common diacritics from basic Latin letters would be helpful.

(I will also add that I strongly agree with you that Zotero should keep the original form of the name in metadata. This should only apply to search.)

It is the weekend so I can't easily ask my web developers for details on how they accomplished it. It only required a 1.5 hour charge.

They changed the collation, and that 1.5 hour is probably mostly spend finding the configuration file and reading the docs. The actual technical change will have been one or two lines of text in a config file, and a restart. SQLite has the plumbing to do new collations, but doesn't have any baked in in the version that's in firefox, and we can't simply re-bake the sqlite in firefox.

Off topic anecdote that doesn't really apply to Zotero citation but only to searching:

When searchers don't know how to "properly" enter a name (or even that there is a "proper" way) they query using what they think is the name.

I'm especially sensitive to the name particle issue (searchers being able to find names with particles with or without entering the particle) because of a SNAFU that happened in my home town when I was about 10 years old. I grew up in south Louisiana "Cajun country". The telephone company switched from operator-connected "number please" calls to dial. Everyone received a new 7-digit number My old home phone number was 21 and my best friend's number was 121. The name problem was with the new telephone book's alphabetization. Almost every family with a name that even a hint of a particle had it dropped. Leblanc (the most common name in town) became listed under B instead of L. Debellvue, another common family name was listed under B. The large Mexican population with Spanish surnames similarly suffered. That would have caused serious confusion under normal circumstances but when everyone was receiving a new phone number it became a disaster. edit: The type was also converted--all upper case to mixed case the name was listed as leBlanc and under B instead of the old Leblanc under "L". People went crazy (with good reason).

Looking at the server logs listing author-name queries it is clear that, depending upon where the user resides, there is a pattern of particle-related name searching. Searchers use or don't use a dropping or non-dropping particle. We received complaints from users who used a form of the name that didn't comply with cataloging rules or various style guides. In fact, for many names more people queried using the "wrong" name-form than the standard one. Thus, our efforts to allow multiple entry formats.