For now the core itself doesn't provide those, but extension can use the hook
to provide them. Callers should not except full coverage in every language.
It's arguable whether the code is cleaner either way, and adding all this code for the (relatively few) places we do file listings just isn't worth it.
2. Add more Accept-Language XVO cache name for IE;
3. Use hreflang to specify canonical and alternate links, it's search engine friendly
when a wiki has multiple variant languages.
Now those two together define the set of namespaces used in the wiki.
$wgExtraNamespaces is for user configuration and overrides, while
$wgCanonicalNamespaceNames is for extension adding their own namespaces.
No code should access those two directly for reading. Instead they should use
MWNamespace::getCanonicalNamespaces.
Also fixed indentation with spaces to tabs in Language.php
As Bawolff pointed out at [[mw:User talk:Simetrical/Collation]], the
prefixing scheme I was using meant that the page "Z" with sort key of
"F" would sort after a page named "A" with a sort key of "FF", since the
first one's raw sort key would compute to "FZ", and the second's would
compute to "FFA". I've fixed this by separating the prefix from the
unprefixed part by a null byte (cl_sortkey is eventually going to be
totally binary anyway, may as well start now).
In response to feedback by Phillipe Verdy on bug 164. Now if a bunch of
pages have [[Category:Foo| ]], they'll sort amongst themselves according
to page name, instead of in basically random order as it is currently.
This also makes storage more elegant and intuitive: instead of giving
NULL a magic meaning when there's no custom sortkey specified, we just
store an empty string, since there's no prefix.
This means {{defaultsort:}} really now means {{defaultsortprefix:}},
which is slightly confusing, and a lot of code is now slightly
misleading or poorly named. But it should all work fine.
Also, while I was at it, I made updateCollation.php work as a transition
script, so you can apply the SQL patch and then run updateCollation.php
and things will work. However, with the new schema it's not trivial to
reverse this -- you'd have to recover the raw sort keys with some PHP.
Conversion goes at about a thousand rows a second for me, and seems to
be CPU-bound. Could probably be optimized.
I also adjusted the transition script so it will fix rows with collation
versions *greater* than the current one, as well as less. Thus if some
site wants to use their own collation, they can call it 137 or
something, and if they later want to switch back to MediaWiki stock
collation 7, it will work.
Also fixed a silly bug in updateCollation.php where it would say "1000
done" if it did nothing, and changed $res->numRows() >= self::BATCH_SIZE
to == so people don't wonder how it could be bigger (since it can't, I
hope).
It seemed to work correctly, with the newly-created page "bob" sorting
as "BOB", but then I nuked all my cl_sortkey by running the migration
script before refreshLinks.php had finished running, so I'll have to
wait a while to see if it works properly with a non-messed-up database.
It's possible there's something wrong with the display of section
letters in the categories, but otherwise I think this is working right.
Hidden behind $wgExperimentalCategorySort until it's reasonably
complete. If that's false, no behavior should change (but I didn't test
carefully, so poke me if there's a bug). See DefaultSettings.php for
documentation on setting it to true. Currently you should not do this
except if you're working on the feature, since functionality is not
close to reasonable yet and will change rapidly.
Bug 1211 is already fixed with this commit for me. However, many other
things still need to be done, so this is all very much a
proof-of-concept.
* Moved the responsibility for calling $wgOut->setPageTitle() from OutputPage::addParserOutputNoText() to the OutputPage/Parser caller. Previously, every call to $wgOut->addWikiText() (or any other message parsing function) was resulting in the title being reset to a converted version of $wgTitle, producing bug 23124. Moving responsibility to the caller seems to work fairly well, since there are apparently only two callers that really want {{DISPLAYTITLE}} etc. to work (EditPage and Article::view).
* Reverted data flow obfuscation in OutputPage::setHTMLTitle() from r64851, replaced by the above. The caller decides what overrides what.
* Reverted inappropriate, cache-polluting references to $wgUser and $wgRequest in Parser::parse(), introduced in r64819.
* Reverted incomprehensible boolean parameter to Language::convert() from r64851, reintroduced Language::convertTitle() instead. Gave it a simpler implementation than before.
* Fixed broken {{DISPLAYTITLE}} feature, was being unconditionally overwritten by the ParserOutput::setTitleText() call in Parser::parse(). Give {{DISPLAYTITLE}} precedence over autoconverted title, like we do for -{T|...}-.
* Tested extensively (perhaps not exhaustively)
* Rename wordSegmentation() to segmentByWord().
* Consolidate search index locking and iteration to Maintenance.php
* Add maintenance/updateDoubleWidthSearch.php to take care of new
format for normalized double-width roman characters.
* Add error checking to updateSearchIndex.php for creating $posFile.
* Add note to UPGRADE about running updateDoubleWidthSearch.php.
