Hello! > From the German example, you can't even do that (name order is different > than dictionary order). I think we are agreed that the default SQLite > implementation gets ASCII right and makes no attempt to deal > specifically with non-ASCII locales. The ICU extension gets all the > locales as right as possible which is why it is huge and slow. > > If I took all the text from a leading newspaper in each locale, how well > would it do. Would it deal correctly with the name of the prime > minister or the capital city? > > An alternate approach would be working with the ICU folks to improve the > size and performance of their library. For example the code could be > refactored to have fast paths for the most common conversions to improve > performance, or be able to omit various lesser used locales to improve > size.
Tcl, Python and other langs have different unicode implementations. The realizations are more simple than ICU library but millions of applications are using these. I'm will glad to see Tcl/Python/etc. unicode implementation in SQLite. I don't need to have text representation for digits and other features from ICU. I did try to create collations from tcl but it's more slow than ICU! And I think we must have different Unicode implementations for UTF8 and UTF16 by performance reasons. ICU works with UTF16 and isn't good for UTF8 databases. Tcl has native encoding UTF16 too. Best regards. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
