In d59f27aeab we made
LanguageConverter::validateVariant() try harder to convert a variant
into an acceptable MediaWiki-internal form, looking at deprecated
codes and BCP 47 aliases. However, this misled Language::hasVariant()
into thinking that bogus names (like all-uppercase strings) were
acceptable variant names, which then led exceptions when they were
passed to the various conversion methods.
This is a belt-and-suspenders patch for T207433 -- in that case we
shouldn't have created a Language object with code 'sr-cyrl' in the
first place, but once one was created we shouldn't have tried to
ask LanguageSr to convert texts to 'sr-cyrl'. The latter problem
is fixed by this patch.
Bug: T207433
Change-Id: Id993bc7989144b5031a551662e8e492bd23f698a
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
setCode changes the language code for the Language object but it also
replaces the whole language codes for all Language objects.
> $lang = Language::factory( 'fr' )
> $lang2 = Language::factory( 'fr' )
> $lang->setCode( 'it' )
> print $lang2->getCode()
it
> $lang3 = Language::factory( 'fr' )
> print $lang3->getCode()
it
Better assign a new Language object.
Also add more tests for Language::equals.
Depends-On: I61439bac82021344c3f9a6056cccd937b3450af2
Depends-On: I2d9e551d6eb33f28f42aeaf48160eba21b83881f
Change-Id: I201b479f58e63c9c40fb8a3ec9575a551fb35235
On a multi-wiki server using a l10n cache, the cache will probably
include aliases from all extensions enabled for any wiki while the
namespaces themselves will only be defined on the wikis where the
extension is loaded.
Bug: T206030
Change-Id: I985dfa3eb17944d5fc0c5be0979be21504fb1341
In the message store, all messages fall through to English,
but only a few languages should actually explicitly fallback
to English (English variants and dialects).
These new explicit fallbacks are used by ResourceLoaderImageModule,
and this change doesn't affect the message fall through system.
Bug: T203350
Change-Id: I6b68a17f4d69341bccdae748727b5133a600d8bc
Before:
Language::fetchLanguageNames( null, 'mwfile' );
After:
Language::fetchLanguageNames( self::AS_AUTONYMS, self::SUPPORTED );
The latter is much more readable and doesn't require knowing the
method definition by heart when seeing it in the code.
I did not add a constant for 'mw' because:
* It is the default value for a last parameter, so it can be left out
* In the long run I expect it will be folded into 'all', see T190129
I did not update any callers; that can be done in follow-ups after
the naming is agreed upon.
Change-Id: Ia9bbb525f213046487f08bcd196876befe87cae8
If you feed this method unescaped data, it can cause later calls
to be an XSS, which is something I think deserves a warning.
Bug: T202571
Change-Id: I34cb3da9232a22defffb80466263c2f2233822ef
* Exclude the data files from PHPUnit coverage.
* Add tests covering the normalize() implementations.
* Fix a small todo about using data providers.
* Set explicit visibility.
Change-Id: Ib104cc3215a36901cff853ad5969d92a6e0cf6a0
This avoids error-prone code written separately in every test. In
addition to no existing tests resetting the TitleFormatter (more
services probably need to be reset as well), they mostly reset only the
namespace cache on $wgContLang, which wouldn't help for any other
language.
The parser test runner still doesn't do this, but maybe it should.
Change-Id: I44b7a1aec48f14b0950907fa14bd0df80f674296
Language::listToText() uses for(;;) which assumes the index in a list
starts at 0 and following keys are consecutive integers.
This assumption fails (and results in warnings with E_STRICT) when
SpecialListGroupRights::formatPermissions() uses the key-preserving
array_intersect() to create a subset of $allGroups.
Bug: T199559
Change-Id: I4eb03a95509d69653156a2764d58c0c5d0d1dfbc
This was split into Language::truncateForVisual() (which measures characters)
and Language::truncateForDatabase() (which measures bytes) in 1.31.
Bug: T197492
Change-Id: I949eab4ceb8dcb707b45edf7623e496eb99fe33b
Language::markNoConversion is used only within Parser.php and differs
from LanguageConverter::markNoConversion in that, contrary to its name
and its namesake, it only protects *things which look like URLs* from
language conversion.
This wasted several days of my time before I realized what was going on.
It's needless; just hoist the "looks like a URL" special casing inline
to the single place where that functionality is used. (And I wonder
if the "looks like a URL" case is actually needed at all any more,
since most of those cases are probably free external links, which
go through a different code path, not bracketed external links.)
This is a clean-up to the clean-up that liangent performed in 2012
with e01adbfc0b.
Change-Id: I80479600f34170651732b032e8881855aa1204d8
In cases where we're operating on text data (and not binary data),
use e.g. "\u{00A0}" to refer directly to the Unicode character
'NO-BREAK SPACE' instead of "\xc2\xa0" to specify the bytes C2h A0h
(which correspond to the UTF-8 encoding of that character). This
makes it easier to look up those mysterious sequences, as not all
are as recognizable as the no-break space.
This is not enforced by PHP, but I think we should write those in
uppercase and zero-padded to at least four characters, like the
Unicode standard does.
Note that not all "\xNN" escapes can be automatically replaced:
* We can't use Unicode escapes for binary data that is not UTF-8
(e.g. in code converting from legacy encodings or testing the
handling of invalid UTF-8 byte sequences).
* '\xNN' escapes in regular expressions in single-quoted strings
are actually handled by PCRE and have to be dealt with carefully
(those regexps should probably be changed to use the /u modifier).
* "\xNN" referring to ASCII characters ("\x7F" and lower) should
probably be left as-is.
The replacements in this commit were done semi-manually by piping
the existing "\xNN" escapes through the following terrible Ruby
script I devised:
chars = eval('"' + ARGV[0] + '"').force_encoding('utf-8')
puts chars.split('').map{|char|
'\\u{' + char.ord.to_s(16).upcase.rjust(4, '0') + '}'
}.join('')
Change-Id: Idc3dee3a7fb5ebfaef395754d8859b18f1f8769a
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Language::fetchLanguageNames returns already a sorted array. An
additional ksort is only needed when inserting a new value.
Change-Id: If8c7b16fa6e7dfe1545f72ac9c742a2f43eaee57
Added an if-else block to see if the parameters passed to the function
designate a year between 1912 and 1941 or not. Resulting month values
are also adjusted.
Added a unit test for the related formatting.
Bug: T68648
Change-Id: Ic676b5c140de8878971a786a1a1811770a848016
Returns the displaytitle (if present) or title->getPrefixedText for a
page, converted for each language variant configured on the wiki.
Bug: T178446
Change-Id: I35100af3824ca65c4fe5c106d4a6fbe4e5f75046
Introduce truncateInternal() method in Language class, based on
existing truncate() method. New method abstracts string truncation,
allowing users to specify callable functions for text length measurement
and string truncation.
New method, truncateInternal(), is used to provide two options for
text truncation:
* For DB usage: truncateForDatabase() method is truncating text by
number of bytes.
* For UI usage: truncateForVisual() method is truncating text by number
of characters, using multibyte string PHP methods.
Old truncate() method is deprecated and just returns the results of
truncateForDatabase() method.
Newly introduced truncateForVisual() method is used for
truncation of long tag descriptions in RCFilters menu.
Bug: T179626
Change-Id: Ib01a8c303304064dde3ce983b817d93a88a5affd
Return the unmodified string if there's no need to truncate it without
doing a not-so-trivial round of getting a message from the message
cache.
Change-Id: I11ac88672aeb9d1c4f5709b79ad2d17223bd64d8
