https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #204 from Aryeh Gregor <simetrical+wikib...@gmail.com> 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, but
> are there simpler backends like BerkeleyDB, dBase files, or flat text files
> for
> small projects supported only via some ODBC driver with a PHP interface ?
We primarily support MySQL. We also have at least theoretical support for
PostgreSQL, SQLite, MSSQL, Oracle, and DB2. However, if this doesn't work for
all DB backends, it's not a big deal, as long as it works with MySQL.
(In reply to comment #201)
> 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 sorting order of specific languages for
> use
> with {{sort:en}} (or whatever the mark-up will be)?
We'll be using some kind of pre-rolled algorithm from CLDR or such, so you
don't need to do this. If the deployed algorithm turns out to be deficient,
and it's not a bug on our side, you should probably contact CLDR, not us.
(In reply to comment #203)
> 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 convert that prefix itself to a
> binary sortkey, it should just still be the humane-readable prefix that was
> specified in {{DEFAULTSORT:sort_prefix}} or in [[Category:...|sort_prefix]].
Yes, this stores the plaintext, unconverted prefix. I don't think the name
needs to be changed, though. Both names work well enough.
> This will avoid confusion, but it will also allow simpler recomputing of
> actual
> sortkeys for various locales, without having to parse the page again for each
> locale:
Yes, that's intended to work.
> Note that when evaluating and expanding the parameters of
> {{DEFAULTSORT:sort_prefix}} and of [[Category:...|sort_prefix]] in the wiki
> code of a page (or when transcluding templates), the result text should NEVER
> depend on the UI language (so if {{int:lang}} is used in that parameter, it
> should evaluate always as if it was {{CONTENTLANGUAGE}}).
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 stage
than category links, so we can't make them behave differently based on whether
they're being used in a sortkey, I don't think. You could also put
{{CURRENTTIME}} in sortkeys, or any other silly thing like that.
--
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
