https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Huji changed:
What|Removed |Added
CC||reza.ene...@gmail.com
--- Comment #237 from Huji
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Brion Vibber changed:
What|Removed |Added
Blocks|29788 |
--
Configure bugmail: https://bugzilla.
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Siebrand changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Phillip Patriakeas changed:
What|Removed |Added
CC||dragonlordofxanther@gmail.c
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Philippe Verdy changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Mark A. Hershberger changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #232 from Philippe Verdy 2011-08-29 01:29:45
UTC ---
If table contents are static, it's true that their collation weights could be
delivered as well with the visible table.
In a past message above, I had already proposed that the fu
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #231 from Bawolff 2011-08-28 23:35:55 UTC ---
Re JS sortable table stuff (this bug is about too many things...): Well client
side js sorting stuff would be nice, since these tables aren't dynamic,
wouldn't it be easier to: on the serv
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #230 from Philippe Verdy 2011-08-27 11:06:18
UTC ---
Until recently, it was too slow to initialize a large table like the DUCET. But
now that Javascript starts being used for 2D/3D rendering with interactive
speed, demonstrating comp
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #229 from Andrew Dunbar 2011-08-27 10:03:28
UTC ---
@Philippe Verdy: I think work on the bigger Unicode problems for JavaScript is
pretty important. I tried to file a bug or feature request somewhere a couple
of years ago and the sen
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #228 from Philippe Verdy 2011-08-26 21:49:23
UTC ---
I am currently working on a Javascript implementation of UCA (i.e. with full
support of the DUCET, at least 4 collation levels, and support for
language-based tailorings). This is
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #227 from Purodha Blissenbach
2011-08-25 16:02:59 UTC ---
> (In reply to comment #224)
>
> Don't forget sortable table sorting.
Sortable tables are sorted client-side. This might offer additional
flexibility. If clients were enable
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Bawolff changed:
What|Removed |Added
CC||bawolff...@gmail.com
--- Comment #226 from Baw
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Siebrand changed:
What|Removed |Added
CC||s.mazel...@xs4all.nl
--- Comment #225 from Si
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Brion Vibber changed:
What|Removed |Added
Blocks||29788
--
Configure bugmail: https://bugz
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Brion Vibber changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #223 from Philippe Verdy 2011-07-20 13:35:21
UTC ---
> The function is not a classical binary search, which only determines equality,
instead it finds the lower bound of a range. When the test item sorts below the
target ($comparison
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #222 from Philippe Verdy 2011-07-20 13:18:31
UTC ---
You should know that a binary search for equality of for lower bound is
completely the same algorithm. (If not convined, look at the source of a C++
standard library, which uses th
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Domas Mituzas changed:
What|Removed |Added
CC||domas.mitu...@gmail.com
--- Comment #221
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #220 from Tim Starling 2011-07-20
12:14:54 UTC ---
(In reply to comment #218)
> if ( $comparison < 0 ) {
> $min = $mid + 1;
> } elseif ( $comparison > 0 ) {
> $max = $mid - 1;
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #219 from Philippe Verdy 2011-07-20 11:20:08
UTC ---
I note the following comment in r80443:
* Changed Title::getCategorySortkey() to separate its parts with a line break
instead of a null character. All collations supported by the i
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #218 from Philippe Verdy 2011-07-20 08:54:53
UTC ---
OK, I immediately found a bug in the binary search function (which is defintely
not beinary, has slower than expected convergence, and may even stale on
testing the same index, due
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #217 from Aryeh Gregor 2011-07-18
18:25:02 UTC ---
The interesting code is here:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Collation.php?view=markup
That's the part that does the actual collation, which is rea
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #216 from Philippe Verdy 2011-07-17 16:50:16
UTC ---
Aryeh, Can you point me with a link where your implementation was added in MW ?
I'd like to review it, and locate possible bugs or caveats.
Also because the announces integration d
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #215 from Aryeh Gregor 2011-07-17
14:12:58 UTC ---
Maybe. It depends. Given the number of comments here and the number of people
being spammed on every post here, though, I'd strongly suggest that people open
new bugs for each plac
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #214 from Niklas Laxström 2011-07-16
11:51:15 UTC ---
There are lots of places where pages are listed - don't they also require or
benefit form such index?
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=emai
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #213 from Aryeh Gregor 2011-07-15
20:12:10 UTC ---
Getting sorting working in other places would require work, but we could use
the same infrastructure. For Special:Allpages, we'd need to add an extra
column and index to the page ta
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Lejonel changed:
What|Removed |Added
CC||lejo...@telia.com
--- Comment #212 from Lejone
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Mark A. Hershberger changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Roan Kattouw changed:
What|Removed |Added
CC||mybugs.m...@gmail.com
--- Comment #210 fr
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Chad H. changed:
What|Removed |Added
CC||pinar.bugzi...@gmail.com
--- Comment #209 from
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Aryeh Gregor changed:
What|Removed |Added
CC||mis...@gmail.com
--- Comment #208 from Ar
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #207 from Philippe Verdy 2010-08-04 17:41:52
UTC ---
In reply to comment #206)
Top-down analyzers are very easy to write, provided that you allow parsing to
be made via TWO generation points, instead of one: the first one converts an
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #206 from Aryeh Gregor 2010-08-04
17:14:25 UTC ---
(In reply to comment #205)
> That's because the Mediawiki parser still operates on the wrong level, and
> performs text subtitutions always without ingoring the context of use. Not
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #205 from Philippe Verdy 2010-08-04 17:09:44
UTC ---
(In reply to comment #204)
> If people want to put crazy stuff in sortkeys that changes based on who's
> viewing it, we can't stop them. Curly braces are evaluated at an earlier
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #204 from Aryeh Gregor 2010-08-03
17:37:45 UTC ---
(In reply to comment #200)
> Which SQL backends (and dialects) do you support in MediaWiki ? This may help
> me understanding some development constraints. I know you support MySQL,
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #203 from Philippe Verdy 2010-07-28 22:18:49
UTC ---
May I even suggest that the name of the new column does not even use "sortkey"
i.e. "cl_sort_prefix" instead of "cl_sortkey_prefix"
Why? because this column should NEVER need to
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #202 from Philippe Verdy 2010-07-28 22:06:54
UTC ---
I would suggest instead making those proposals in the CLDR project.
It already contains lots of data for many languages, related to their expected
"sort order" (in fact more genera
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #201 from V85 2010-07-26 23:02:33 UTC ---
For those of us who are less technical, but keen to see this bug resolved, is
there somewhere where we can submit alphabets, so that they may be added for
collation? I.e. where we submit the s
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #200 from Philippe Verdy 2010-07-26 22:44:37
UTC ---
Note that if your collator stub does not really compute true sort keys
(compacted in binary format and representing collation weights), it may return
spaces (U+0020), that is repre
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #199 from Philippe Verdy 2010-07-26 22:23:47
UTC ---
>> (Note also that section headings ("first letter") will have to be
>> "translated"
>> to correctly report the "first letter" of the Pinyin romanization, because
>> the
>> page
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #198 from Aryeh Gregor 2010-07-26
21:43:21 UTC ---
(In reply to comment #187)
> Drop this tacking immediately in the PHP code: the cl_sortkey is only intended
> to store the clear-text sortkey "hint" specified in {{DEFAULTSORT:sortke
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #197 from Philippe Verdy 2010-07-26 21:01:11
UTC ---
I note that you have started to define the Collator class as the Language
class.
Well I'm not sure that this should be the same class: a language has several
collators, even if a
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #196 from Philippe Verdy 2010-07-26 20:37:46
UTC ---
Note that the CollatorFactory may fail to locate the specified locale for which
a collator is being requested. Additionally, several locales may share exactly
the same collator.
I
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #195 from Aryeh Gregor 2010-07-26
19:50:19 UTC ---
By the way, I'm keeping track of progress here:
http://www.mediawiki.org/wiki/User:Simetrical/Collation
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=emai
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #194 from Aryeh Gregor 2010-07-26
19:49:15 UTC ---
(In reply to comment #190)
> Yes Language::firstLetterforList(s) maps more or less to COLLATIONMAP, but
> COLLATIONMAP is a more generic concept which reflects what is defined in
> U
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #193 from Philippe Verdy 2010-07-26 19:41:57
UTC ---
Exemple of interface for you:
'')
$locale .= '-x-' . $options; // append sort options if any (like 'uc', 'lc')
$level = 1; //use collation level 1 by default
$collator = $wgCo
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #192 from Philippe Verdy 2010-07-26 19:20:35
UTC ---
Note that this is the minimum functional interface for the Collator class.
Other methods will be certianly needed to cache the already prepared collators,
or to cache the preloaded
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #191 from Philippe Verdy 2010-07-26 19:07:34
UTC ---
In all this discussion it appears that the development can be made in two
separate projects developped independantly.
You can continue to develop the SQL schema extension, provide
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #190 from Philippe Verdy 2010-07-26 18:38:10
UTC ---
Yes Language::firstLetterforList(s) maps more or less to COLLATIONMAP, but
COLLATIONMAP is a more generic concept which reflects what is defined in
Unicode standard annexes, which
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #189 from Aryeh Gregor 2010-07-25
17:22:32 UTC ---
(In reply to comment #186)
> That'a a bad assumption : even the highest quality collations will need to be
> updated from time to time:
> - Unicode evolves and new characters get enc
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #188 from Philippe Verdy 2010-07-24 07:00:47
UTC ---
(In reply to comment #183)
> Okay, look, if you make posts this long I'm not going to be able to read
> them.
> You have to state your points briefly and clearly, or else I'm jus
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #187 from Philippe Verdy 2010-07-24 06:17:18
UTC ---
(In reply to comment #185)
> Oh, I didn't get what he was saying. Yes, obviously we should use the actual
> cl_from field, not tack it onto cl_sortkey (is that what we do these da
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #186 from Philippe Verdy 2010-07-24 05:53:30
UTC ---
(In reply to comment #183)
> Upgrading the collation can be done in-place. The worst case is that
> categories sort weirdly for a few hours. Also, we would only realistically
> h
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #185 from Aryeh Gregor 2010-07-22
18:47:23 UTC ---
Oh, I didn't get what he was saying. Yes, obviously we should use the actual
cl_from field, not tack it onto cl_sortkey (is that what we do these days?).
I'm going to have to make
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #184 from Roan Kattouw 2010-07-22 18:40:19
UTC ---
(In reply to comment #183)
> It is not needless. We need a unique key to sort by, or else paging doesn't
> work if many pages have the same sort key (e.g., if it was manually
> ass
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #183 from Aryeh Gregor 2010-07-22
17:57:42 UTC ---
Okay, look, if you make posts this long I'm not going to be able to read them.
You have to state your points briefly and clearly, or else I'm just not going
to have time to read thr
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #182 from Philippe Verdy 2010-07-22 13:18:28
UTC ---
Note that my developement plan will NOT imply an immmediate change of the SQL
schema. At first, if only working on the frist 2 steps, no schema change is
necessary to effectively t
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #180 from Philippe Verdy 2010-07-22 11:42:55
UTC ---
Your issue ***IS*** addressed in my proposal:
*Both* {{COLLATIONMAP:Áa}} and {{COLLATIONMAP:Aa}} will be unambiguously "aa"
in the primary collation level for that locale. They on
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #179 from Roan Kattouw 2010-07-22 11:16:18
UTC ---
(In reply to comment #178)
> All this is something that can be avoided completely by using ICU and not
> depending on SQL backends for their support of many more collation locales
Th
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #178 from Philippe Verdy 2010-07-22 10:48:39
UTC ---
Because his specification is really incomplete, and he said that Bug#164 was
useless (despite of the fact that I had described my solution extensively in
Bug#164long before Ariyeh
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #177 from Roan Kattouw 2010-07-22 10:17:54
UTC ---
(In reply to comment #176)
> Anyway, the Aryeh's proposal is not found or documented at the location you
> indicate. It just says that he will try to work on it today and still asks
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #176 from Philippe Verdy 2010-07-22 10:04:53
UTC ---
Anyway, the Aryeh's proposal is not found or documented at the location you
indicate. It just says that he will try to work on it today and still asks for
solutions and asks for qu
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #175 from Roan Kattouw 2010-07-22 09:59:32
UTC ---
(In reply to comment #174)
> > If we're gonna discuss anything, let's
> discuss the current implementation plan: it is the only relevant plan to
> discuss at this point.
>
> This is
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #174 from Philippe Verdy 2010-07-22 09:13:30
UTC ---
> If we're gonna discuss anything, let's
discuss the current implementation plan: it is the only relevant plan to
discuss at this point.
This is EXACTLY what I was discussing: pro
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #173 from Roan Kattouw 2010-07-22 07:15:01
UTC ---
(In reply to comment #172)
> And this was false. Because you assume that the generation of sort keys has to
> be done on database queries for listing the content of a category, when
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #172 from Philippe Verdy 2010-07-22 06:00:34
UTC ---
>> But if the SQL engine does not have such support, this must be implemented in
>> the PHP code and collation keys can be stored in a new datacolumn (the extra
>> data column can
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|wikibug...@li
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Tim Starling changed:
What|Removed |Added
CC||tstarl...@wikimedia.org
--- Comment #170
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Liangent changed:
What|Removed |Added
CC||liang...@gmail.com
--- Comment #169 from Lian
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #168 from Aryeh Gregor 2010-03-14
16:26:48 UTC ---
Changing cl_sortkey to utf8 *is* a solution. It needs a sysadmin to do it on
Wikimedia (if we want to do it), and we'd probably also want some core code to
filter out non-BMP charac
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #167 from T. Gries 2010-03-12 22:38:48 UTC ---
(In reply to comment #166)
> This shouldn't be an extension, we may as well have a page_sortkey added in
> core. Makes more sense there. However, categories are lower-hanging fruit,
> s
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #166 from Aryeh Gregor 2010-03-12
22:30:03 UTC ---
This shouldn't be an extension, we may as well have a page_sortkey added in
core. Makes more sense there. However, categories are lower-hanging fruit,
since we just need to change
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #165 from T. Gries 2010-03-12 22:18:10 UTC ---
(In reply to comment #164)
> (In reply to comment #163)
> The options I know of are:
> 1) Use MySQL collation support, just using utf8 everywhere. This will mess up
> equality comparison
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #164 from Aryeh Gregor 2010-03-12
22:06:57 UTC ---
(In reply to comment #163)
> Thanks for pointing out. I must admit, that you are _fully_ right, also
> knowing
> of the collation differences. We developers should collaboratively t
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #163 from T. Gries 2010-03-12 21:47:56 UTC ---
(In reply to comments #159 and #160)
> While the suggested patch clearly dramatically improves the page title
> sorting,
> it doesn't make it 100% correct for all "European languages" th
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #162 from Huji 2010-03-12 17:48:42 UTC ---
(In reply to comment #160)
Actually, I think the issues you raised with collations and languages has
nothing to do with MediaWiki; if anything, MySQL is to be blamed. All we want
here is for
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #161 from Aryeh Gregor 2010-03-12
17:12:17 UTC ---
utf8 support in MySQL supports a number of common languages, including Danish,
Swedish, French, Hungarian, and Estonian:
http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-sets.
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #160 from Stu Derby 2010-03-12 01:32:28 UTC ---
Re: comment 159
While the suggested patch clearly dramatically improves the page title sorting,
it doesn't make it 100% correct for all "European languages" though it may make
it so fo
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
T. Gries changed:
What|Removed |Added
CC||m...@tgries.de
--- Comment #159 from T. Gries
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Le Chat changed:
What|Removed |Added
AssignedTo|philip@gmail.com|wikibug...@lists.wikimedia.
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Le Chat changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #158 from Le Chat 2010-02-27
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Chris changed:
What|Removed |Added
CC||chriskwonle...@msn.com
--- Comment #157 from
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #156 from Andrew Dunbar 2009-11-27 21:50:21
UTC ---
Apparently non-BMP UTF-8 was in MySQL 6.0 which was around as alpha for a while
and whose features are all due to be added into upcoming 5.X versions:
http://lists.mysql.com/pa
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #155 from Andrew Dunbar 2009-11-27 02:07:39
UTC ---
Here is another related MySQL bug to watch:
http://bugs.mysql.com/bug.php?id=25666
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You a
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #154 from Philippe Verdy 2009-11-25 23:06:01
UTC ---
That's another good resson why collation should be supported directly within
the MediaWiki software, which already depends completely of PHP, so that it
should really use the
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #153 from Andrew Dunbar 2009-11-25 07:57:50
UTC ---
MySQL can do the collation that Anthony mentions for PostgreSQL above in #152
and much more besides.
PostgreSQL has all the problems and more of MySQL when it comes to MediaWi
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
Anthony changed:
What|Removed |Added
CC||bugzi...@inbox.org
--- Comment #152 from A
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #151 from Philippe Verdy 2009-11-20 15:43:56
UTC ---
Anyway, the backend compatibility layer that maps the SQL into the SQL dialect
spoken by the SQL engine can still adapt itself : if there's a true support for
collation suppor
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #150 from Peter Gervai (grin) 2009-11-20 15:09:45
UTC ---
Well I didn't want to chime in (you seem to be able to shout at each others
without my assistance :-)) but please do not forget that the solution for
MEDIAWIKI (as oppose
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #149 from Andrew Dunbar 2009-11-20 11:05:53
UTC ---
I've added some feedback on the MySQL bug. I urge anyone here who cares about
this bug to also pay attention to that bug. Perhaps by working on their code,
perhaps voting for t
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #148 from Philippe Verdy 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, includi
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #147 from Andrew Dunbar 2009-11-20 01:50:55
UTC ---
MySQL does support CLDR/UCA collation and I believe it to be fast. The reason
we don't use it is that MySQL does not support the full range of Unicode
whereas MediaWiki does. M
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #146 from Philippe Verdy 2009-11-20 00:11:53
UTC ---
I did not make assumptions about SQL engines, because this message exactly says
the opposite: there are varieties there, and Mediawiki could/should also work
with other SQL ba
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #145 from Roan Kattouw 2009-11-19
22:13:25 UTC ---
(In reply to comment #144)
> Some SQL engines (like Oracle, Sybase, Informix, but probably not all index
> formats supported in various versions of MySQL) also store the rowID's
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #144 from Philippe Verdy 2009-11-19 18:12:31
UTC ---
Note that in SQL, the ORDER BY clause needs NOT unique sort keys.
Not even for sort stability, because the SQL engine will ensure the sort
stability itself from the default st
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #143 from Philippe Verdy 2009-11-19 17:58:47
UTC ---
(in reply to comment #142 from Roan)
>The pageID was just added to make sure that the sort key was unique (actually
>> this is not a requirement),
> It is a requirement softw
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #142 from Roan Kattouw 2009-11-19
16:40:25 UTC ---
(In reply to comment #141)
> The pageID was just added to make sure that the sort key was unique (actually
> this is not a requirement),
It is a requirement software-wise. If tw
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #141 from Philippe Verdy 2009-11-19 16:09:07
UTC ---
#137 From Roan Kattouw 2009-11-19 14:17:38 UTC
>(In reply to comment #134)
>> Tdoday, basically, the categories are sorted by [sort key, full page name].
>> (possibly truncate
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #140 from Philippe Verdy 2009-11-19 15:59:48
UTC ---
#138: I fully agree. Using stored collation keys will remove the dependency
with the database support, and will also avoid the problem of downtime when
upgrading the collation
1 - 100 of 153 matches
Mail list logo
