https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #148 from Philippe Verdy <[email protected]> 2009-11-20 04:25:06 UTC --- May be it's low in their priority, but with the development of Unicode and the now ongoing efforts to add now many more characters in plane 1 (notably lots of symbols, including common things like circled letters and numbers) and 2 (ideographs) for modern use, this position will become unmaintainable, and the need for extending the MySQL UTF-8 support will increase. After all, MySQL is now controled by Sun, which is an active member of Unicode Technical Commity, and even Sun will want a better interfaction with its Java platform that has excellent Unicode implementation and is used as a reference platform (even before the newest algorithms are ported to C/C++). ICU is also supported by IBM that has a strategic need in C/C++, Java, and intergration in web services (both on the server- and client-side of applications). Here also IBM wants itegration with its dB2 SQL platform but has siognificant offers over MySQL. Both companies (also Apple, Oracle, and many others) are highly engaged in the Unicode development process, internationalisation, and want support for their platforms (including in China, where currently MySQL will not be an option, as long as full support of Unicode will not be there). in fact, extending the support to the missing plnes is now a small effort in comparison to what has already been made by them. And another refernce platform (Perl) can also help generate the missing code or data tables that are needed (the PHP platform makes no efforts itself, as its Unicode support completely depends on ICU now, which is now a reference library that is becoming nearly universal on all platforms, with the except of Windows where Microsoft has rewritten everything in its CLR for .Net). May be MySQL will sooner or later replace its own implementation simply by integrating ICU, to save the collaborative efforts... The only seriously missing development for collation for now is on the client side: we still lack a good support of collation in Javascript (which just as a string.localeCompare(string) method with an unspecified collation table, and incompatible implementations across browsers with lots of bugs.): the few demonstrations that I have seen need to use server-side components to actually collate or process the Unicode data through AJAX! I think that this will come when JSP server-side applications will start to want Collators without depending on native libraries (that cannot be deployed easily from servers to servers, or over computing grids). Collator factories should become as universal in I18N framewaorks, as it is now for translation resource bundles, date/time formats, case mappings, encoding convertors, and regular expressions. So are there voluntaries to implement it in MediaWiki using its native PHP platform (through the intl10n library), independantly of MySQL (which is just a backend, from which MediaWiki should not heavily depend exclusively). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
