Do not split parser cache if limitation is reached.
authorBrian Wolff <bawolff+wn@gmail.com>
Mon, 28 Sep 2015 22:39:31 +0000 (16:39 -0600)
committerBrian Wolff <bawolff+wn@gmail.com>
Mon, 28 Sep 2015 22:39:31 +0000 (16:39 -0600)
The warnings are only shown during preview. It seems silly to
split the parser cache for this. There should be no parser cache
pollution to just using the user language without registering it
for use.

See also: 889e988ccec3428a10c831

Change-Id: Ib42e8885e23a3c8bef8cf72948359d71254064c3

includes/parser/Parser.php

index 3b49ccf..bbee9d4 100644 (file)
@@ -3385,6 +3385,8 @@ class Parser {
         * Warn the user when a parser limitation is reached
         * Will warn at most once the user per limitation type
         *
+        * The results are shown during preview and run through the Parser (See EditPage.php)
+        *
         * @param string $limitationType Should be one of:
         *   'expensive-parserfunction' (corresponding messages:
         *       'expensive-parserfunction-warning',
@@ -3407,8 +3409,10 @@ class Parser {
         */
        public function limitationWarn( $limitationType, $current = '', $max = '' ) {
                # does no harm if $current and $max are present but are unnecessary for the message
+               # Not doing ->inLanguage( $this->mOptions->getUserLangObj() ), since this is shown
+               # only during preview, and that would split the parser cache unnecessarily.
                $warning = wfMessage( "$limitationType-warning" )->numParams( $current, $max )
-                       ->inLanguage( $this->mOptions->getUserLangObj() )->text();
+                       ->text();
                $this->mOutput->addWarning( $warning );
                $this->addTrackingCategory( "$limitationType-category" );
        }