The documentation didn't make it clear that the wfMsgExt() array can take a single associative parameter. I've clarified this, and fixed error-checking for that. Also adjusted indentation in the comment for clarity (one space isn't enough).
This seems to make code much uglier and harder to maintain -- there are a bajillion new calls to "wfMsgExt( 'pipe-separator' , 'escapenoentities' )" which is not trivial or easy to remember. This makes code uglier, harder to read, harder to maintain, and more prone to error.
This seems to be a little funny, though, at least on commons -- the commonswiki:sitenotice:https=1 key is just storing 'false' so it presumably gets reparsed on each run. I can't see any way that this should be happening, which is a little intimidating...
* (bug 13815) In the comment for page moves, use the colon-separator message instead of a hardcoded colon.
* So that this works properly, don't escape HTML entities in edit summaries. I don't see any good reason for them to be escaped there. Of course, this may result in old edit summaries displaying slightly differently if for some reason they included an entity, but in that case there's at least a 50% chance that they intended it to not be escaped in the first place.
* Do not add action=edit to nonexistent special pages.
* Add profiling point for the bit where we add classes in linkAttribs().
* Turn makeLinkObj(), makeKnownLinkObj(), makeBrokenLinkObj() into wrappers for link(). This requires the creation of two new functions to turn query strings/attribute strings into arrays, but still results in fewer LOC (-11 lines) due to less code duplication. This should be well-tested by the parser tests, because pretty much all link creation now goes through link(), but the only changes are encoding single quotes in attributes, which is a good change. I find no additional database queries, so since this isn't a CPU bottleneck, there should be no performance issues.
"* (bug 13815) In the comment for page moves, use the colon-separator message instead of a hardcoded colon."
"* So that this works properly, don't escape HTML entities in edit summaries. I don't see any good reason for them to be escaped there. Of course, this may result in old edit summaries displaying slightly differently if for some reason they included an entity, but in that case there's at least a 50% chance that they intended it to not be escaped in the first place."
This breaks the ability to easily discuss entities in summaries such as "add ".
* So that this works properly, don't escape HTML entities in edit summaries. I don't see any good reason for them to be escaped there. Of course, this may result in old edit summaries displaying slightly differently if for some reason they included an entity, but in that case there's at least a 50% chance that they intended it to not be escaped in the first place.
This implements an mb_str_pad fallback function, but there is no mb_str_pad in PHP documentation, and the doc comments are really weird -- it says it returns an integer!
If this function is created from whole cloth and doesn't exist in PHP, it should be given a MediaWiki style name and not be done with a function_exists check as though it were a compat function.
As a general rule, it would be a good idea to first split the functions off into their own file without changing them, and then refactor them in a separate commit. Otherwise it's very hard to follow what's actually being changed. (git actually tracks changes to functions when they're moved across files, incidentally, which is quite awesome.)
* Code duplication of validity checks between wfIsValidFileName() and UploadForm::internalProcessUpload() -- this guarantees behavior will become inconsistent over time. Move the normalization into a single place.
* The additional chars excluded for Windows don't cover the entire set of illegal chars. There are several more punctuation characters, plus general issues such as all non-ASCII characters.
* Application of filesystem rules based on OS could result in strange inconsistent behavior; alternate filestore backends could support different sets of legal characters.
* No clear reason for the change to wfVarDump(); var_export works just fine and doesn't use the fragile output buffering
This would make maintenance harder by duplicating information between GlobalFunctions.php and CompatibilityFunctions.php. If you forget to add a function to the list, the compat functions might not get loaded and you'll run into surprise errors.
