Move ZhConversion.php and Names.php to languages/data and make them both
expose their data as static class variables instead of in the local
scope. This means that the autoloader can be used to load the data,
which is efficient and secure. This also makes additional request-local
caching of the arrays unnecessary.
Change-Id: Iafb96ac4165d0965fcb9a69f1d0a91139ea9790c
Previously various language objects would install a hook to update the
shared conversion table cache when the object was constructed. This is
not a good idea since language objects may be constructed even when they
are not the content language, but only the content language is
associated with variant conversion and the conversion cache.
Instead, have WikiPage call a method on $wgContLang directly. I put this
with message cache update since the logic is almost identical.
Change-Id: Ief9c0ef993e39645e74a6e158cb4e6e2139ce91d
* Remove strcspn() check in newFromCode already in isValidCode().
* Leverage the autoloader instead via class_exists instead of
including files based on user input.
* Create fallback instance directly instead of recursing back
into newFromCode().
* Remove method preloadLanguageClass (unused).
* Remove method getClassFileName (unused)
Change-Id: I90035ca4b07facae051b1a584e92df72b42c4a49
To detect whether the truncation had chopped up a multibyte
character after the first byte, a regex was used. But in this
regex, the dot (.) didn't match newlines, so it failed to
detect chopped multibyte characters (after the first byte)
if there was a newline preceding the chopped character.
Bug: T116693
Change-Id: I66e4fd451acac0a1019da7060d5a37d70963a15a
Changed some old bugzilla links to new phabricator links in comments,
test data and error message. This reduces the need for redirects from
old bugzilla to new phabricator from our source code.
Change-Id: Id98278e26ce31656295a23f3cadb536859c4caa5
* If using 'default', still fallback to 'date' if 'pretty' is
unavailable.
* Fix instance caching of 'default', which never worked since $pref
would be changed inside the !isset() block.
Bug: T110945
Change-Id: Ic53b279f8741371fa1cb642c53e6d487cb1c6b81
The xenon logs on performance.wikimedia.org show this function as being on-CPU
about 1% of the time, making it a candidate for optimization. The version in
this patch is about 30-50% faster in my benchmarks.
Change-Id: I26385ade7600fc11965d94468b57e41ec257de51
Any page on translatewiki with param setlang=qqq times out. All messages
get parsed recursively until parser-template-loop-warning is reached.
uselang=qqq is already ignored, see RequestContext::sanitizeLangCode.
There is a counterpart to this patch in ULS, where it is changed
to use Language::isSupportedLanguage.
Bug: T104987
Change-Id: Ie77fe18681dfd5f9089fbaa8090dd9cc1c206da4
strtr() is marginally faster as it runs through the string only
once. A better fit for one-for-one character translation.
The strtr() function also supports an associative array as second
parameter for entire string replacements. This, too, has the same
performance and predictable behaviour (starts with the longest key).
Whereas str_replace is for more aggressive needs where you want
multiple passes until there are no further matches.
The associative array form is arguably also easier to understand
and harder to mess up since the needle/replacement pairs are
explicitly connected instead of two separate arrays.
Also:
* Use getFormattedNsText instead of strtr( getNsText, .. ) which
reduces duplication of this fact through a more semantic intent.
Change-Id: Ie23e4210a5b6908dd79eebc8a2b931d12fe31af6
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
The 'fallbackSequence' is exactly generated for this purpose. It
is equal to the value of 'fallback' after splitting, trimming
and ensuring 'en' is present. See LocalisationCache::recache().
Also simplify returning of the first array index by returning it
directly instead of modifying the array first.
Due to an inconsistency between how LocalisationCache and Language classes
treat the fallback sequence differently, we have to manually fallback
to 'en' in case of unknown language codes. This is because otherwise
Language::factory() will throw an exception causing tests to fail.
We should investigate whether this is desirable or not, but keeping
existing behaviour for now and documenting it.
Change-Id: I9c1d51b59aabebf5a31f38205304bb8cc22dcd8c
Use arrays instead of strings, to avoid using
string functions with Unicode.
Handle thousands according to how years like 1000, 2000, etc.
are named in the Hebrew Wikipedia.
Bug: T97444
Change-Id: I5334e86793d28dfcf8939a249b03a5ea85fa4e69
We're trying to remove MediaWiki dependencies from MWTimestamp so it can
be split out into a separate library. In addition to getting rid of a
dependency on RequestContext, Language, and User, it makes more logical
sense there anyways.
Bug: T100924
Change-Id: If46eaea42d8a5a808c10f0dc353e181714295a44
This drops support for the custom utf8 normal PHP extension in favor
of the intl extension.
Bug: T90825
Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.
Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.
* Many extension callers of Language::formatExpiry() with $format !==
true are assuming it'll return 'infinity', none are checking for
$db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
but some stuff is comparing it with $db->getInfinity() anyway. A few
external users set mExpiry to $db->getInfinity(), but this is mostly
because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
manually doing it, once we make that safe to call with 'infinity' for
all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
$db->getInfinity(), when all the inserts using that value are using
$db->encodeExpiry() which will convert 'infinity'.
This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.
Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
Refactor out 'infinity' vartiant values which used in blocking and
protecting actions. This patchset adds GlobalFunction wfIsInfinity.
Bug: T68646
Change-Id: I60cc55a5bbd43c72916a1c2ea3807457d4e33765
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Deprecated it in Title, and updated all current references to use the
non-deprecated version in MediaWikiTitleCodec
Change-Id: I2b9c36992028c97f695f2b95ba027fbb11904b57
Right now, SpecialPageFactory::getAliasListObject() just chooses the
last-seen alias and allows any alias to completely override the page's
"canonical" name (from SpecialPageFactory::$list or $wgSpecialPages).
Although the latter doesn't come up often since (almost?) all special pages
have their canonical name as one of their English-language aliases.
More sensible behavior is to always prefer the "canonical" name over any
conflicting aliases, and to prefer an alias that's the first alias for a
special page over one that is a fallback.
Also, when a special page's first alias winds up not actually referring
to that special page, we MUST NOT go redirecting other names for that
special page to that wrong alias.
Bug: 70686
Change-Id: I4b17ec0fdc87b4b0d7ae9d9eea7ffacb54dd6891
Since it is slow and is called many times when articles with lots of
interlanguage links are viewed.
Change-Id: Ib826ea6f1c105ffd43e456fb1c0c3b8aa6d8e391
Also, try out a way to have per-module LESS variables defined in PHP.
This might come in handy in the future… Maybe for skin theme support?
(I recommend reviewing the file changes in the order below. :D)
includes/resourceloader/ResourceLoaderFileModule.php
* Pass the context (ResourceLoaderContext) deeper down via
readStyleFiles() and readStyleFile(). We need it to compile the
.less files for the right language.
* Extract LESS compiler creation to getLessCompiler().
* Allow passing a LESS compiler instance to compileLessFile(), rather
than getting one after the method is called.
All of the changes are backwards-compatible.
includes/resourceloader/ResourceLoaderEditToolbarModule.php
* New module to support getting the language data and passing it to
LESS variables.
It might be a good idea to factor out a reusable class for a LESS
module with additional variables, but that would require more
attention to design than I gave it.
resources/src/mediawiki.action/mediawiki.action.edit.toolbar/mediawiki.action.edit.toolbar.less
* Glue code to use the language data defined by the module above and
put it in final CSS.
includes/EditPage.php
* Do not hardcode image URLs in output HTML, as they are provided in
CSS now. This gets rid of some usage of globals.
In fact, we should be able to finally move the inline JavaScript
calls out of getEditToolbar(), but I'm already introducing too many
changes for one patch. That can be done later.
languages/Language.php
* Add getImageFiles() to complement existing getImageFile() method.
Misleadingly named, it returns paths for images for the toolbar
only (and no other ones at all).
skins/common/ → resources/src/mediawiki.action/mediawiki.action.edit.toolbar/
* Moved all of the button images to new location.
Also, boring cleanup that was harder before because we treated the
paths as public API:
* Placed default ones in en/ subdirectory.
* Renamed cyrl/ to ru/.
* Renamed ksh/button_S_italic.png → ksh/button_italic.png.
languages/messages/
* Adjusting paths and filenames for the changes above.
resources/src/mediawiki.action/mediawiki.action.edit.css
resources/src/mediawiki.action/mediawiki.action.edit.js
* Added styles and updated the script to make it possible to have
non-<img> elements as toolbar buttons.
* Consolidated styles that were already required, but defined
somewhere else:
* `cursor: pointer;` (from shared.css)
* `vertical-align: middle;` (from commonElements.css)
Bug: 69277
Change-Id: I39d8ed4258c7da0fe4fe4c665cdb26c86420769c
This code path gets triggered when I run unit tests locally and
produces billions of lines of output. I don't care why, I just want it
to shut up.
Change-Id: I09a5cbaea80ff9d7afc22c83f972890cfa25d127
