Last modified: 2014-03-10 13:20:03 UTC
The "completion" feature and probably some other places of input are missing unicode normalization. For example, while using the interface in French, when adding a Definition: - select the blank Languague field - start type "franc" and "français" is offered as a valid language - add a combining mark to have "franç" and no language is offered anymore "ç" and "ç" are equivalent, the expected result is the same for either.
Now, "c" and "ç" both allow français to be displayed in the combobox. So, it has been solved apparently.
No this hasn't been fixed. Try these three: (ASCII) franc <U+0066 U+0072 U+0061 U+006E U+0063> (NFC) franç <U+0066 U+0072 U+0061 U+006E U+00E7> (NFD) franç <U+0066 U+0072 U+0061 U+006E U+0063 U+0327> ASCII and NFC will give the expected result: français, français canadien, français de Belgique, français de France, français de Suisse, francoprovençal NFD does not give any language in the list. NFC and NFD should return the same result. For Unicode NFC and NFD represent the same string. What is recent is ASCII and NFC giving the same result.
Bugzilla normalizes to NFC. So in my example NFD and NFC are both saved and displayed as NFC. Use the codepoints if you want to actually use NFD. In HTML code: franç
For those who don't know, these acronyms are explained there: http://www.unicode.org/reports/tr15/ The problem also appears for the ellipsis / 3 points.
Could you check again with the ç now? It seems to almost work, except that the function that puts the searched string in bold does not work with NFD (if I understood that correctly this time)
Cool. It seems to have been fixed. Now "francais", "français" and "français" give the same results. Merci Kip ! But yes, when using combining characters (NFD) it is not bolded.
