Entirely misses the point. The original document was discussing the problem of text normalization, which still remains.
If I have a database of employee bios and I write an app so HR can search that database, it's no problem for them to type in "management" and get a list of all employees with the word "management" in their bio. But when a division does the same thing in a non-English-speaking country where there's an é in the word, then that word can be composed of either two characters or one and searching one way will tend to miss any results which were composed of text the other way. The solution here is to normalize the data before it is stored in the DB and the search term before it is searched for.
It's a simple concept. Not all programmers are aware of it, however, and this guy totally missed the point.
If I have a database of employee bios and I write an app so HR can search that database, it's no problem for them to type in "management" and get a list of all employees with the word "management" in their bio. But when a division does the same thing in a non-English-speaking country where there's an é in the word, then that word can be composed of either two characters or one and searching one way will tend to miss any results which were composed of text the other way. The solution here is to normalize the data before it is stored in the DB and the search term before it is searched for.
It's a simple concept. Not all programmers are aware of it, however, and this guy totally missed the point.