Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
These are static methods that have to do with processing language names
and codes. I didn't include fallback behavior, because that would mean a
circular dependency with LocalisationCache.
In the new class, I renamed AS_AUTONYMS to AUTONYMS, and added a class
constant DEFINED for 'mw' to match the existing SUPPORTED and ALL. I
also renamed fetchLanguageName(s) to getLanguageName(s).
There is 100% test coverage for the code in the new class.
This was previously committed as 2e52f48c2e and reverted because it
depended on e4468a1d6b, which had to be reverted for performance
issues. There should be no changes other than rebasing.
Bug: T201405
Change-Id: Ifa346c8a92bf1eb57dc5e79458b32b7b26f1ee8a
The test fills $wgUrlProtocols with 86000 entries, forging oversized
strings which ends up eventually truncated to 100 bytes. The aim is to
overflow $wgAPIMaxResultSize to trigger an apiwarn-truncatedresult
warning.
The test takes 230 ms on my machine and when generating code coverage
almost a minute.
A faster approach is just to lower the $wgAPIMaxResultSize limit to
trigger the warning.
Test plan:
$ php tests/phpunit/phpunit.php \
tests/phpunit/includes/api/ApiQuerySiteinfoTest.php \
--filter testContinuation
Bug: T234016
Change-Id: I3dc96d394d8b98dda8f151d14544b829c92f9b10
Now that resetServices() will preserve (but reset) customized services,
it should be reasonably safe to call it every time globals are changed,
and much more effective than relying on tests to call it every time
themselves.
Depends-On: Iab8ea3a61bbc6803805d855ef23c071067646f71
Depends-On: I00e35ecea6a27468674b2a6e7d9d9eb6518e3bd5
Change-Id: Ie7a89f6ed7d52a0bc01672019ff92e7ee105a1f3
These are static methods that have to do with processing language names
and codes. I didn't include fallback behavior, because that would mean a
circular dependency with LocalisationCache.
In the new class, I renamed AS_AUTONYMS to AUTONYMS, and added a class
constant DEFINED for 'mw' to match the existing SUPPORTED and ALL. I
also renamed fetchLanguageName(s) to getLanguageName(s).
There is 100% test coverage for the code in the new class.
Change-Id: I245ae94bfc1f62b6af75ea57525139adf2539fe6
MediaWiki uses a number of nonstandard codes which do not validate
according to the IANA language subtag registry. Some of them have
the wrong semantics entirely: MediaWiki's `sr-ec` variant maps to
BCP 47 `sr-EC` which is "Serbian as used in Ethiopia" (!).
Extend LanguageCode::bcp47() to map our nonstandard codes to valid
BCP 47 language codes. Export the mapping so that it can be used
in JavaScript's corresponding mw.language.bcp47() implementation
as well, and return the standard BCP 47 codes in the siteinfo
API.
Thanks to TheDJ (I10b4473c7e53f027812bbccf26bb47aec15fddfd) and
Fomafix (I93efc190714ba76247d30ba49fc21ae872fc3555) for previous
attempts at this!
Also removed a fixme for the name of 'Twi', dating back to 2004
(f59c3be23b) -- checking
tw.wikipedia.org it certainly appears that the autonym of 'Twi'
is correctly 'Twi'.
Tracking bugs for invalid language codes are T125073 and T145535.
Discussion of zh-XX => zh-HanX-XX mapping is at T198419.
This is a replay of an earlier merged patch,
8380f0173e, which had to be reverted
because it caused regressions in the Babel extension (T199941).
Bug: T34483
Bug: T106367
Bug: T120847
Depends-On: I27a5b8e45b34c6b57c1b612b11548001c88cd483
Change-Id: Iebbc604af21d7f2af9c1f1ab2574cb5f309bf6ed
This method encourages directly editing configuration variables. It's a
better idea to use setMwGlobals() (or other set wrappers) so that we can
be intelligent in the future, for instance resetting services after the
config change. Plus, a lot of the callers come out cleaner this way
anyway.
Depends-On: I8a1e81acc5c42a8d7f30938a72cface0acea4a70
Depends-On: I4105dbcf9c5399fe7239478c460ec57c015a98d4
Depends-On: I1b220996acf2f66cf7b0f092b341584663df32f9
Depends-On: Ie2d1ea65c0cb334bbde1666d00781474b7ac4dab
Change-Id: I23d77398e401f4986b1d5bd1c9e11a8a40da16f8
So callers don't need to do this manually. Pointed out by Tim in T201799.
Depends-On: Ia6c36d5a650095e35093bf47e275e081e89b3daf
Change-Id: Ida62767f3ca53f99609cae01d3a20051bb92ccab