For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
They should be Ș, Ț (comma-below) and instead they were cedilla-below (Ş, Ţ).
Same as for Romanian (ro) in 486f64f283.
Both of these languages are unsupported by libicu and so the collations
are unlikely to have been used in practice.
Bug: T171043
Bug: T171044
Change-Id: Idd0d593e73cd784fbef7b75e8985f988f5555e26
Can't just clear cache on production, as this
now uses per-server apc instance.
Follow-up 486f64f283
Change-Id: I88df6d5a91c86ef687543d1a6988e0ec050bbfce
This is based on a numeric uppercase collation. Bashkir characters
will be remapped to the private use area for the purpose of sorting.
Bug: T162823
Change-Id: I65f1af0b57ff6ded7d464e39efd401f178a3519e
We have several such collations defined in IcuCollation:
* bs-Cyrl
* de-AT@collation=phonebook
* fr-CA
* sr-Latn
They couldn't actually be used.
Change-Id: I3a62073583c49d3e90910aa8240fe9fcc0682386
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: I6f59febaf8fc96e80f8cfc11f4356283f461142a
We have to use a tertiary sortkey for everything with the primary
sortkey of 2627. Otherwise, the "Remove duplicate prefixes" logic
in IcuCollation would remove them.
The following characters will now be considered separate letters in
the 'xx-uca-fa' collation for the purpose of displaying the headings
on category pages: ء ئ ا و ٲ ٳ
Bug: T139110
Change-Id: Ibbea5d76348e4cdc38b74cba44286910b2ed592f
Instances of subclasses of IcuCollation with customizations for
specific languages probably shouldn't share this cache with instances
of IcuCollation with the same language.
Change-Id: I06d66d199c99448a3375381baef0366c4d99c8c4
This is based solely on looking at the bn.txt collation data
file. It has not been tested by native speakers.
Bug: T148885
Change-Id: Ide926bc5ee8752269ef6a1bfe972e19b7188d193
At this point I think it's safe to assume that these mostly work well,
and the split makes maintenance of the alphabetical list more difficult
(some entries were already in wrong order). We've been enabling these
collations for more and more Wikimedia wikis and not hearing about any
problems. Mistakes, if any are present, should be treated like any
other bug.
Also made some comments consistent.
Change-Id: I4b5fbcf4dbbdd4dc194ed821341296171fa64bb0
Based on CLDR 29 data files.
This did the relatively easy languages in CLDR 29 (Which is most
of them). I skipped languages with complicated tailoring files.
Change-Id: I8367604f7d3a1cdef9cb4e15813893c8cbfff1ff
This will cause the numeric collation to sort localized digits
for the current content language the same as how 0-9 are.
This only deals with the localized digit numbers, commas
and other number formatting are still not handled. Weird
"numerical" unicode characters are also not handled.
I was unsure if to make a "family" of numeric collations
where you specify numeric-<lang code>, or if it should
just use $wgContLang. Given that $wgContLang effectively
never changes, and also affects all other digit handling,
I opted to just use $wgContLang.
Any wikis currently using the 'numeric' collation will
have to have updateCollation.php --force run after this
change is deployed. At the moment that includes:
bnwiki, bnwikisource and hewiki
Bug: T148873
Change-Id: I9eda52a8a9752a91134d1118546b0a80d3980ccf
A few more languages marked as "Verified by native speakers",
based on which collations we've been using in production
on Wikimedia wikis.
(I'm not sure if this makes sense now that we're fairly confident
that these are good in general, but since it's already here...)
Change-Id: I8e1f31fa61509eca8c76a2df4e18638005e68b77
This collation orders text with numbers "naturally", so that
'Foo 1' < 'Foo 2' < 'Foo 12'.
Note that this only works in terms of sequences of digits, and the
behavior for decimal fractions or pretty-formatted numbers may be
unexpected.
This is only expected to work mostly correctly for English-language
text. Consider it a proof of concept. You probably want to use
an UCA collation with '-u-kn' suffix rather than this.
Bug: T8948
Change-Id: Ie268f2d92c5c75d0aaecf54ede2bdda1af3b309d
To use, add '-u-kn' to the end of a collation name and set it as
the value for $wgCategoryCollation.
Bug: T8948
Change-Id: Ica7908daf80624fa2648127114d01665e96234c0
Small optimization to IcuCollation::fetchFirstLetterData().
This used to suppress / restore warnings once per every letter of
every alphabet. The workaround for string casting and error
suppression is no longer needed as of PHP 5.3, in which the
bug was fixed.
Change-Id: Idd41a509858c0887df4f632b480b387bd74027b2
* Factor out fetchFirstLetterData() as a separate method.
* Move 'version' into the key instead of checking afterwards.
* Use getWithSetCallback() for the cache handling.
(Depends on version being in the key).
Change-Id: I15bddf5d1dabcdcef47a938447ba59436bd8a294
I noticed that `frwiki:first-letters:fr🇫🇷4.8.1.1` was at the very top of keys
sorted by bandwidth (that is, reqs/sec * size) on one of the memcache servers
on WMF prod.
The data takes ~60 - 80ms to compute, in case of a cache miss. That's not
enough to justify using a tiered cache abstraction here, IMO.
Change-Id: If81ce8f86f2c378565f1f6a0dd2c04dee825c4e9
