The space is actually used inside extensions, such as Maps, covertly called as 'display_map' into
Validator, then converted into 'display map' by getName().
Registering a tag hook with < or > on its name resulted in a UNIQ marker.
Spaces, tabs or LF do work (CR fails due to the CR->LF transformation),
but it's easier to also forbid them, just as they are not allowed in other
markup languages.
For environments post r70783, they will need to rerender pages with __NOEDITSECTION__ or no headings (hopefully those will be simple pages).
There will be no extra parser cache misses for environments pre r70783.
Doing this allows skins to override doEditSectionLinks without poluting the parser cache or fragmenting the parser cache more.
As a side effect it eliminates the primary cause of user language based parser cache fragmentation.
Because this makes most old parser cache entries invalid $wgUseEditSectionTokens is provided so that large installations like Wikipedia can keep their old parser cache entries.
has a % sign in it, but interperted as a + if no % sign is present.
This changes how the parser interperts links slightly. However:
*I can't imagine anyone is relying on this behaviour
*Things should be consistent. a + sign shouldn't magically change meaning
if there is a % sign somewhere else in the link.
*Pages are allowed to contain % signs in their title, and + signs,
you should be able to link to such pages just by typing there name without
resorting to %2B.
*If you have a page named foo%+ having [[{{PAGENAME}}]] link to a different
page seems inherently wrong.
*The previous behaviour seemed accidental.
* Removed other usages of $wgUser in Parser stuff, as stated in doc
* Added mechanism to get an User object in Parser, based either on the object given in Paser::preSaveTransform() or the ParserOptions otherwise
The issue is, php strtolower() calls tolower(3), which is locale sensitive.
Eg. LC_ALL='pt_BR.ISO-8859-1' php -r'echo strtolower("ÉÁÇÚÍ");'
Adding a call to setlocale(LC_ALL,'C'); in Setup.php may be a good idea.
None of the 3 globals based on it changed if you set it in LocalSettings.
Note that all those !isset( $wgServerName ) in ApiTests were useless, since if not in LocalSettings it would be 'localhost', not null (as still are those !isset( $wgServer )).
sed -i 's/$wgContLanguageCode/$wgLanguageCode/g'
These are now the same, always. Per and since r15827.
$wgLanguageCode wins due to being the one set by LocalSettings.
$wgContLanguageCode definition at includes/Setup.php kept for now.
use the same parsercache entry for articles without <math> tags.
The cache key format is kept as a fallback so the old cached entries can be reused.
Should boost parsercache hits, but it also makes easier to pollute the parsercache by tag hooks that behave
badly, directly using $wgUser or $wgLang.
Extensions hooking PageRenderingHash now see !edit=0 and the !printable=1 bits.
Fixes bug 24714 - Usage of {{#dateformat: }} in wikis without $wgUseDynamicDates can lead to unexpected results
Builds upon r70498, r70498, r70501, r70517, r70651, r70653, r70765, r70780.
Now works (again?) in IE6. That didn't like getting non-legacy ID's on
redirects -- it doesn't interpret them as UTF-8, so anything non-ASCII
breaks. If this works in all the browsers I test in, I'll enable it --
it will produce *much* nicer-looking anchors for non-English wikis, and
also section names with English punctuation.
