So callers don't need to do this manually. Pointed out by Tim in T201799.
Depends-On: Ia6c36d5a650095e35093bf47e275e081e89b3daf
Change-Id: Ida62767f3ca53f99609cae01d3a20051bb92ccab
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.
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.
Bug: T34483
Bug: T106367
Bug: T120847
Change-Id: I807dd55d49e9bd19443329231326a5b0d3e6c453
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
The siteinfo API response's 'writeapi' value is now hard-set to true,
as are the ResourceLoader variables wgEnableAPI and wgEnableWriteAPI,
to be deprecated later.
Bug: T115414
Change-Id: I54ff9428b247ba203d67aba079149393f323d5a9
Without this fix, the situation is that a query for 'siprop=dbreplag'
shows a db server with lag=0, while the siprop=dbreplag&sishowalldb=1
query shows the same server having non-zero lag. That's confusing.
Regression from r47865 (88f35cdf6e).
Change-Id: Id4854c8453206a6f1f8c369dc89c3a8bd910f83f
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
Include the value of $wgCategoryCollation in the siteinfo general array. This will allow AWB to get this information without needing to scrape the NOC InitialiseSettings.php.txt file.
Bug: T179795
Change-Id: I76f85c71d2fe0d7a0482fb5eda0458708057e48d
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
LanguageConverter is enabled on a per-page basis, based on the page
language and whether it implements `$lang->getConverter()`. Export
this in siteinfo so that Parsoid knows whether it should parse
language converter markup on a given page (based on the page language).
Bug: T153341
Change-Id: I010aa3812051725166ab79ea5ee3eaf56615fe94
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: I49e2a10350a328a8572fcedd44012751a29e1068
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
These variables control how MediaWiki normalizes page titles.
Clients need to know these settings to not be surprised by such normalization.
See T94826.
Change-Id: Id77f584b8c3a3d9c065993bd74525f166112b20c
Currently, an user of the api has to try to save a page to see,
if it's too big, or not. A much saner way would be, that the api user
reads the siteinfo of the target wiki to know the maximum size of a
page and trim the edit to not exceed this limit.
This commit exposes the value of the configuration variable, which
handles the maximum article size.
Bug: T138669
Change-Id: I25a4c1b9013f98e5b0a263a637c8b006dccfd5ad
In $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and
$wgGroupsRemoveFromSelf, boolean true in place of an array of groups to
allow adding/removing is shorthand for "all groups". Handle this
appropriately in action=query&meta=siteinfo&siprop=usergroups.
Bug: T135467
Change-Id: I6ae61ef14ac7932e3369155c56bad60a9d72060d
This aims to solve all the problems and fulfill all the use cases.
It allows the dialog to be configured for Wikimedia Commons without
hardcoding anything, and it should be flexible enough for third-party
use. The default configuration should be sane for any wiki.
The file upload dialog can be configured using $wgUploadDialog.
See DefaultSettings.php for documentation. Example configuration for
Wikimedia Commons: Id56370e2334c8fe34e88180356232b48c244b7c4.
Configuration is loaded using ResourceLoaderUploadDialogModule for
local uploads or using ApiQuerySiteinfo (action=query&meta=siteinfo)
for uploads to a foreign wiki. Custom localisation messages may be
loaded using action=query&meta=allmessages.
Renamed messages:
upload-form-label-own-work-message-local -> upload-form-label-own-work-message-generic-local
upload-form-label-not-own-work-message-local -> upload-form-label-not-own-work-message-generic-local
upload-form-label-not-own-work-local-local -> upload-form-label-not-own-work-local-generic-local
upload-form-label-own-work-message-default -> upload-form-label-own-work-message-generic-foreign
upload-form-label-not-own-work-message-default -> upload-form-label-not-own-work-message-generic-foreign
upload-form-label-not-own-work-local-default -> upload-form-label-not-own-work-local-generic-foreign
Deleted messages, moved to WikimediaMessages in Id2977e19330aeaf854157d4355cd17e5dc72f16a:
upload-form-label-own-work-message-shared
upload-form-label-not-own-work-message-shared
upload-form-label-not-own-work-local-shared
Bug: T118097
Bug: T120998
Bug: T121632
Bug: T121633
Bug: T127895
Change-Id: I3017b8f09c27625deb7a92d6f667895b71cc0637
meta=siteinfo gets a list of all configured central ID lookup providers
and which one is being used as the default, while meta=userinfo,
list=users, and list=allusers get the ability to return the IDs and
attachment status.
Change-Id: Iea15b6c22baac79b3f8ca6df0e20a6a4299507d2
This was originally made 'BCarray' to avoid breaking BC, but in this
case the nonstandard output is so rare it's probably best to just be
internally consistent.
Bug: T117022
Change-Id: I501c415f6170383c163110b00e54ac88c3dfec89
Paths to ./composer.lock is changed to ./vendor/composer/installed.json
and dependency information now is read from the installed.json file.
A new ComposerInstalled class has been declared and uses the class now
to access the getInstalledDependencies() method to read data
Bug: T106247
Change-Id: Ic216577bb19b4fc5832ba003fcbbe9195d707b41
This fixes a few shortcomings in the chunked uploader:
* Raises an error if offset + chunksize > filesize.
* Enforces a minimum chunk size for non-final chunks.
* Refuses additional chunks after seeing a final chunk.
* Status of a chunked upload in progress is now available with
'checkstatus'.
Bug: T91203
Bug: T91205
Change-Id: I2262db1bc8460616b069c564475d2e4148001768
Use message-per-value for message
apihelp-query+siteinfo-param-prop to allow smaller strings
for translation.
Each prop in a message also will show up a new parameter on the help
page without the adjust of the translation (but than in english instead
of fully skip it).
Change-Id: I458fddcaef1cc96656a87375eff9707c8ba0db94
The main change is that siprop=namespaces will output an array instead
of a numerically-keyed object with formatversion=2.
Various other properties also got the same treatment, but in those cases
the intention was always array and possible non-array output was due to
array_unique or odd indexes in config variables.
Bug: T102645
Change-Id: I486131ac0d6763c3fe40fa45bcee472fe1b46fd6
Since T98757 is talking about changing this (whether by default or not),
we should probably make it accessible via the API.
Change-Id: I8cd08b214171866208a65181f772de9f2e315cd9
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
