wiki.techinc.nl/includes/resourceloader/ResourceLoaderLanguageDataModule.php

82 lines
2.5 KiB
PHP
Raw Normal View History

<?php
/**
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
* @author Santhosh Thottingal
*/
use MediaWiki\MediaWikiServices;
/**
* Module for populating language specific data, such as grammar forms.
*
* @ingroup ResourceLoader
* @internal
*/
class ResourceLoaderLanguageDataModule extends ResourceLoaderFileModule {
protected $targets = [ 'desktop', 'mobile' ];
/**
* Get all the dynamic data for the content language to an array.
*
mediawiki.jqueryMsg: Refactor test suite to not make any API requests This test was an awful, awful, mess. (And I take full responsibility.) Changing the global user language mid-way into execution is in no way supported by ResourceLoader and this test was going through great lengths to fool mw.loader about what's really going on. Basically, all we're doing is get a list of instructions on what tests to run, get comparison values based how the PHP side proceses these (for parity comparison), and then run the assertions. The mw.language singleton already has support for multiple languages, and mediawiki.jqueryMsg already supports injecting data and constructing new instances for each test case. Make use of that :) Instead of calling ResourceLoaderLanguageDataModule::getData by trying to hot load the same module repeatedly from load.php, just export this data using 'packageFiles'. The mediawiki.jqueryMsg QUnit suite previously took 4s to run locally and now only 0.1s (145ms). This is not only significant for this particular module, but also for QUnit in general as Headless Chrome only took about 7s to run all of MediaWiki core's test suites prior to this change, which is now down to ~3s. (MacBook Pro) For WMF CI: * Before (master commit): - mediawiki.jqueryMsg.test: ~2.1s (2135ms) - MediaWiki core total: ~4.8s * After (this patch): - mediawiki.jqueryMsg.test: ~0.015s (15ms) - MediaWiki core total: ~3.6s Bug: T250045 Bug: T225730 Change-Id: I5f1067feb0a43d63bfc5e7fff5110285a5e433c8
2019-10-04 18:49:07 +00:00
* @internal Only public for use by GenerateJqueryMsgData (tests)
* @param string $langCode
* @return array
*/
public static function getData( $langCode ) : array {
$language = MediaWikiServices::getInstance()->getLanguageFactory()
mediawiki.jqueryMsg: Refactor test suite to not make any API requests This test was an awful, awful, mess. (And I take full responsibility.) Changing the global user language mid-way into execution is in no way supported by ResourceLoader and this test was going through great lengths to fool mw.loader about what's really going on. Basically, all we're doing is get a list of instructions on what tests to run, get comparison values based how the PHP side proceses these (for parity comparison), and then run the assertions. The mw.language singleton already has support for multiple languages, and mediawiki.jqueryMsg already supports injecting data and constructing new instances for each test case. Make use of that :) Instead of calling ResourceLoaderLanguageDataModule::getData by trying to hot load the same module repeatedly from load.php, just export this data using 'packageFiles'. The mediawiki.jqueryMsg QUnit suite previously took 4s to run locally and now only 0.1s (145ms). This is not only significant for this particular module, but also for QUnit in general as Headless Chrome only took about 7s to run all of MediaWiki core's test suites prior to this change, which is now down to ~3s. (MacBook Pro) For WMF CI: * Before (master commit): - mediawiki.jqueryMsg.test: ~2.1s (2135ms) - MediaWiki core total: ~4.8s * After (this patch): - mediawiki.jqueryMsg.test: ~0.015s (15ms) - MediaWiki core total: ~3.6s Bug: T250045 Bug: T225730 Change-Id: I5f1067feb0a43d63bfc5e7fff5110285a5e433c8
2019-10-04 18:49:07 +00:00
->getLanguage( $langCode );
return [
'digitTransformTable' => $language->digitTransformTable(),
'separatorTransformTable' => $language->separatorTransformTable(),
'minimumGroupingDigits' => $language->minimumGroupingDigits(),
'grammarForms' => $language->getGrammarForms(),
'grammarTransformations' => $language->getGrammarTransformations(),
'pluralRules' => $language->getPluralRules(),
'digitGroupingPattern' => $language->digitGroupingPattern(),
'fallbackLanguages' => $language->getFallbackLanguages(),
'bcp47Map' => LanguageCode::getNonstandardLanguageCodeMapping(),
];
}
/**
* @param ResourceLoaderContext $context
* @return string JavaScript code
*/
public function getScript( ResourceLoaderContext $context ) {
return parent::getScript( $context )
. 'mw.language.setData('
. $context->encodeJson( $context->getLanguage() ) . ','
mediawiki.jqueryMsg: Refactor test suite to not make any API requests This test was an awful, awful, mess. (And I take full responsibility.) Changing the global user language mid-way into execution is in no way supported by ResourceLoader and this test was going through great lengths to fool mw.loader about what's really going on. Basically, all we're doing is get a list of instructions on what tests to run, get comparison values based how the PHP side proceses these (for parity comparison), and then run the assertions. The mw.language singleton already has support for multiple languages, and mediawiki.jqueryMsg already supports injecting data and constructing new instances for each test case. Make use of that :) Instead of calling ResourceLoaderLanguageDataModule::getData by trying to hot load the same module repeatedly from load.php, just export this data using 'packageFiles'. The mediawiki.jqueryMsg QUnit suite previously took 4s to run locally and now only 0.1s (145ms). This is not only significant for this particular module, but also for QUnit in general as Headless Chrome only took about 7s to run all of MediaWiki core's test suites prior to this change, which is now down to ~3s. (MacBook Pro) For WMF CI: * Before (master commit): - mediawiki.jqueryMsg.test: ~2.1s (2135ms) - MediaWiki core total: ~4.8s * After (this patch): - mediawiki.jqueryMsg.test: ~0.015s (15ms) - MediaWiki core total: ~3.6s Bug: T250045 Bug: T225730 Change-Id: I5f1067feb0a43d63bfc5e7fff5110285a5e433c8
2019-10-04 18:49:07 +00:00
. $context->encodeJson( self::getData( $context->getLanguage() ) )
. ');';
}
/**
resourceloader: Enable module content version for data modules This greatly simplifies logic required to compute module versions. It also makes it significantly less error-prone. Since f37cee996e, we support hashes as versions (instead of timestamps). This means we can build a hash of the content directly, instead of compiling a large array with all values that may influence the module content somehow. Benefits: * Remove all methods and logic related to querying database and disk for timestamps, revision numbers, definition summaries, cache epochs, and more. * No longer needlessly invalidate cache as a result of no-op changes to implementation datails. Due to inclusion of absolute file paths in the definition summary, cache was always invalidated when moving wikis to newer MediaWiki branches; even if the module observed no actual changes. * When changes are reverted within a certain period of time, old caches can now be re-used. The module would produce the same version hash as before. Previously when a change was deployed and then reverted, all web clients (even those that never saw the bad version) would have re-fetch modules because the version increased. Updated unit tests to account for the change in version. New default version of empty test modules is: "mvgTPvXh". For the record, this comes from the base64 encoding of the SHA1 digest of the JSON serialised form of the module content: > $str = '{"scripts":"","styles":{"css":[]},"messagesBlob":"{}"}'; > echo base64_encode(sha1($str, true)); > FEb3+VuiUm/fOMfod1bjw/te+AQ= Enabled content versioning for the data modules in MediaWiki core: * EditToolbarModule * JqueryMsgModule * LanguageDataModule * LanguageNamesModule * SpecialCharacterDataModule * UserCSSPrefsModule * UserDefaultsModule * UserOptionsModule The FileModule and base class explicitly disable it for now and keep their current behaviour of using the definition summary. We may remove it later, but that requires more performance testing first. Explicitly disable it in the WikiModule class to avoid breakage when the default changes. Ref T98087. Change-Id: I782df43c50dfcfb7d7592f744e13a3a0430b0dc6
2015-06-02 17:27:23 +00:00
* @return bool
*/
resourceloader: Enable module content version for data modules This greatly simplifies logic required to compute module versions. It also makes it significantly less error-prone. Since f37cee996e, we support hashes as versions (instead of timestamps). This means we can build a hash of the content directly, instead of compiling a large array with all values that may influence the module content somehow. Benefits: * Remove all methods and logic related to querying database and disk for timestamps, revision numbers, definition summaries, cache epochs, and more. * No longer needlessly invalidate cache as a result of no-op changes to implementation datails. Due to inclusion of absolute file paths in the definition summary, cache was always invalidated when moving wikis to newer MediaWiki branches; even if the module observed no actual changes. * When changes are reverted within a certain period of time, old caches can now be re-used. The module would produce the same version hash as before. Previously when a change was deployed and then reverted, all web clients (even those that never saw the bad version) would have re-fetch modules because the version increased. Updated unit tests to account for the change in version. New default version of empty test modules is: "mvgTPvXh". For the record, this comes from the base64 encoding of the SHA1 digest of the JSON serialised form of the module content: > $str = '{"scripts":"","styles":{"css":[]},"messagesBlob":"{}"}'; > echo base64_encode(sha1($str, true)); > FEb3+VuiUm/fOMfod1bjw/te+AQ= Enabled content versioning for the data modules in MediaWiki core: * EditToolbarModule * JqueryMsgModule * LanguageDataModule * LanguageNamesModule * SpecialCharacterDataModule * UserCSSPrefsModule * UserDefaultsModule * UserOptionsModule The FileModule and base class explicitly disable it for now and keep their current behaviour of using the definition summary. We may remove it later, but that requires more performance testing first. Explicitly disable it in the WikiModule class to avoid breakage when the default changes. Ref T98087. Change-Id: I782df43c50dfcfb7d7592f744e13a3a0430b0dc6
2015-06-02 17:27:23 +00:00
public function enableModuleContentVersion() {
return true;
}
/**
* @return bool
*/
public function supportsURLLoading() {
return false;
}
}