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
This removes Language::$dataCache without deprecation, because 1) I
don't know of a way to properly simulate it in the new paradigm, and 2)
I found no direct access to the member outside of the Language and
LanguageTest classes.
Change-Id: Iaa86c48e7434f081a53f5bae8723c37c5a34f503
Example use case: in some skins we want to show how many *days* ago a page was edited, but we don't really care about the precise _hours_.
Thus we'll set [ 'avoid' => 'avoidhours' ] when calling Language#formatTimePeriod to output something like "Page last edited 60 days ago" instead of "Page last edited 60 days 9 hours ago".
Change-Id: I0a737aab14ccb2b8d4eccdc41e1eb9232eedcb8a
Different PHP versions treat unicode differently, and specifically some
wiki resources become unreachable if mb_strtoupper's behavior has changed.
This patch allows to introduce an override table that allows to smooth
the transition period.
It also provides maintenance scripts to generate such an override table.
Bug: T219279
Change-Id: I0503ff4207fded4648c58c7b50e67c55422a4849
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
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
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
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
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
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
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
I removed comments that merely repeated the location of the class being
tested. There are other tests in this directory that don't have a
corresponding class and need further investigation.
Change-Id: Ic16f0887b5030ac53fab4382cfaedfb5426cdb08
Guarded by the $wgUsePigLatinVariant variable, off by default.
Pig Latin is a language game where words in English are altered
according to the following rules:
* Words starting with a vowel have a '-way' suffix appended.
* Words starting with a consonant have the initial consonants (or 'qu'
group) moved to the end and an '-ay' suffix appended.
https://en.wikipedia.org/wiki/Pig_Latin
* Added 'en-x-piglatin' as a language name.
* Added 'en' to LanguageConverter::$languagesWithVariants.
* Added LanguageEn class and its corresponding EnConverter which
provides one-way translation from English to Pig Latin.
* Some minor internal changes in code that assumed that English
doesn't have a language class or converter.
Bug: T45547
Depends-On: I1d9691c784032669979f8109c9a5f65cbf4122c9
Change-Id: I7fa2d85d6364958c5138366e8b4504a2697a8731
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
For relative timestamps in $str, strtotime( $str, $now ) returns an
absolute Unix timestamp $str since $now, and this timestamp is given
to $time. However, Language::formatDuration expects a time duration,
not an absolute timestamp. We obtain this duration from the difference
between $time, the absolute timestamp of block expiry, and $now, the
absolute timestamp of the time in which the block action happened.
Tests have been added to test both this patch and 01936fa, the patch
that caused this regression.
Bug: T156453
Change-Id: I6fd8c02dc3c6456067fe25cb9f33f5b4c78332aa
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
"B" and "P" are vanishingly rare abbreviations for "bytes" and "pixels"
respectively. Let's use the full English terms for these, combined with
a PLURAL magic word for good measure.
Change-Id: Id59c4b9dea2c13940ae790b6a236ac08abe0a768
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
Some failing tests are commented out and will be properly fixed
in subsequent commits.
Bug: T97444
Change-Id: I19721b5dc3dc6bbe923d9bf401fcf5d765fb7a7c
MediaWiki default is "@return type Description", so set a type after
return and start the description with a capital letter. Also use the
more common spelling of boolean.
See http://phpdoc.org/docs/latest/references/phpdoc/tags/return.html for
more about @return
Change-Id: I4e5198822fe92836f9cef9918a9fc1a1a1e0a043
The results of this function are used to decide whether a code is
valid for loading an i18n file without any further normalization.
Partially reverts 93348f3 which made the regular expression case-
insensitive. Per IRC discussion, language codes should always be
lowercase and it's up to callers to deal with that.
Change-Id: I8975c3374a37935080d9f7eca6a602e32f67a87b
Add an out parameter to Language::sprintfDate that returns the amount of
time that its output is valid for (e.g., an output format of 'Y-m-d' at
11:50 PM would be valid for 600 seconds).
Change-Id: I3f5a80aa4d303f92c97d24ab780af920894d24ef
When parsing, filter any array values that are empty string
before using strtr php function so that strtr can handle
the array.
Bug: 64347
Change-Id: I94761caa70d44febfa0999c91048a01044fc1fbe
Localization of numeric values should operate on the values as strings,
and should handle strings representign very large numbers gracefully.
Change-Id: I95394b96f9b70deb06ab818b54e08ac4ccb38c6c
When truncating a string at a point where it contains a space (ie "hello
world" to 9 chars), the resultant string will have a space before the
ellipsis ("hello ..."). This is both gramatically incorrect and just looks
wrong, and is fixed by trimming the string before appending the ellipsis.
Change-Id: Iec86b17bfc8c50e4c1a96fd373861841fc57848d
This change:
- Adds method scope
- adds @covers tags
- adds various @todos
- fixes some comments
Before the changes tests ran with:
1383 tests, 1412 assertions 10 skips
After changes the results remain the same
Change-Id: Iee57447bdb47026952ef5dcce6fed5dad0f80e52
Currently if the site language is zh and a user is using variant zh-tw,
namespace names from zh-hant are displayed because of the language
converter, but they're not accepted by MediaWiki as valid namespace names
by default because zh falls back to zh-hans.
For core namespaces, all converted namespace names are manually added as
$namespaceAliases in MessagesZh.php but it's not always done in extensions.
With this patch converted namespace names are automatically added as
namespace aliases when namespace aliases are loaded.
In some followup commit it makes sense to remove existing core namespace
aliases which were created for this reason.
Change-Id: I01873d9c64a9943afbb655d6203cec9ebd39fb72
It is possible that only explicit plural forms are specified, and
therefore, it is possible that none match. However, handling of
explicit forms came after the count( $forms ) check, so input such
as {{PLURAL:|1=}} would trigger a "PHP Notice: Undefined offset: -1".
Change-Id: I8494de8ceb9e0cfff7203c69c21f02b3731275af
Follows-Up: I50eb0c6d1c02ca936848d310de625ed1fe43d91a
