Change Details

From https://www.mediawiki.org/wiki/Manual:Wiki_ID "The wiki ID (or database ID) is the most common way of identifying a wiki within a wiki farm in MediaWiki. When every wiki is in a separate database, it is simply the database name; when multiple wikis share a database and are differentiated with table prefixes, it is in the form <db name>-<table prefix>. It can be retrieved by calling wfWikiID()." Back in the days before Wikibase, no one external to the server much cared what the database was named internally. The database name might have been exposed as the prefix to a few cookies, overrideable by https://www.mediawiki.org/wiki/Manual:$wgCookiePrefix but otherwise didn't affect much of anything. Wikibase introduced the concept of a GlobalID (such as 'dewikivoyage' or 'enwiki') being publicly displayed every time an inter-language link was created on a Wikidata-style repository. The WikiID reported by the API was suddenly important, as the API was being queried in various places, including the Wikibase repository extension (when a new inter-language link is supplied by the user, to see if the page exists) and the Pywikibot extension (for functionality like interwikidata.py - which imports inter-language links). The presumption was that the WikiID matches the GlobalID matches the database name and prefix. Worse yet, the idea that the hard-coded global naming convention was a language code (such as 'pt') followed by a project name which began in 'wiki*' or 'wiktionary' ( see https://phabricator.wikimedia.org/T172076 ) might have made sense on Wikimedia's cluster (where the databases happened to have those names already) but almost always didn't match the existing database names on other, non-Wikimedia projects. There is a configuration setting in the Wikibase extension, $wgWBRepoSettings['localClientDatabases'][(...GlobalID...)]=...database name...; which does a translation from GlobalID to database name, but only within the Wikibase code and only in one direction (GlobalID to database name). There is no corresponding translation in the opposite direction - as that would have to be part of the API, which is core code. If my existing internal database names look like "myproject_xx" and "myproject_xx" for language xx: and xy: (which are not mutually intelligible) but the GlobalID's for the projects were xxmyproject and xymyproject (because Wikibase seems to be expecting everything to follow WMF-like naming conventions) then there's no way (at least in MW 1.31) to force the API to report the proper GlobalID short of changing includes/api/ApiQuerySiteinfo.php protected function appendGeneralInfo( $property ) to make the substitution (from MW1.31, insert after line 247): $wikiid = wfWikiID(); this kludge to report in the WikiID field the externally-known 'GlobalID' to ensure compatibility with interwikidata.py: if (substr($wikiid,0,9)=='myproject_') $wikiid=substr($wikiid,9) . 'myproject'; The only other alternative is to rename every existing database so that the database name is forced to be the externally-reported GlobalID. That's doable, but it seems a bit inconsistent that a translation table like $wgWBRepoSettings['localClientDatabases'][] exists in some portions of the code but not others. Effectively, the use of $wgWBRepoSettings['localClientDatabases'][] to match GlobalID's to dissimilar local database names does not work, as the underlying database name is still being externally reported by the API. The database name and prefix must therefore still match the GlobalID, or things (such as Pywikibot's interwikidata.py) break.

From https://www.mediawiki.org/wiki/Manual:Wiki_ID "The wiki ID (or database ID) is the most common way of identifying a wiki within a wiki farm in MediaWiki. When every wiki is in a separate database, it is simply the database name; when multiple wikis share a database and are differentiated with table prefixes, it is in the form <db name>-<table prefix>. It can be retrieved by calling wfWikiID()." Back in the days before Wikibase, no one external to the server much cared what the database was named internally. The database name might have been exposed as the prefix to a few cookies, overrideable by https://www.mediawiki.org/wiki/Manual:$wgCookiePrefix but otherwise didn't affect much of anything. Wikibase introduced the concept of a GlobalID (such as 'dewikivoyage' or 'enwiki') being publicly displayed every time an inter-language link was created on a Wikidata-style repository. The WikiID reported by the API was suddenly important, as the API was being queried in various places, including the Wikibase repository extension (when a new inter-language link is supplied by the user, to see if the page exists) and the Pywikibot extension (for functionality like interwikidata.py - which imports inter-language links). The presumption was that the WikiID matches the GlobalID matches the database name and prefix. Worse yet, the idea that the hard-coded global naming convention was a language code (such as 'pt') followed by a project name which began in 'wiki*' or 'wiktionary' ( see https://phabricator.wikimedia.org/T172076 ) might have made sense on Wikimedia's cluster (where the databases happened to have those names already) but almost always didn't match the existing database names on other, non-Wikimedia projects. There is a configuration setting in the Wikibase extension, $wgWBRepoSettings['localClientDatabases'][(...GlobalID...)]=...database name...; which does a translation from GlobalID to database name, but only within the Wikibase code and only in one direction (GlobalID to database name). There is no corresponding translation in the opposite direction - as that would have to be part of the API, which is core code. If my existing internal database names look like "myproject_xx" and "myproject_xy" for language xx: and xy: (which are not mutually intelligible) but the GlobalID's for the projects were xxmyproject and xymyproject (because Wikibase seems to be expecting everything to follow WMF-like naming conventions) then there's no way (at least in MW 1.31) to force the API to report the proper GlobalID short of changing includes/api/ApiQuerySiteinfo.php protected function appendGeneralInfo( $property ) to make the substitution (from MW1.31, insert after line 247): $wikiid = wfWikiID(); this kludge to report in the WikiID field the externally-known 'GlobalID' to ensure compatibility with interwikidata.py: if (substr($wikiid,0,9)=='myproject_') $wikiid=substr($wikiid,9) . 'myproject'; The only other alternative is to rename every existing database so that the database name is forced to be the externally-reported GlobalID. That's doable, but it seems a bit inconsistent that a translation table like $wgWBRepoSettings['localClientDatabases'][] exists in some portions of the code but not others. Effectively, the use of $wgWBRepoSettings['localClientDatabases'][] to match GlobalID's to dissimilar local database names does not work, as the underlying database name is still being externally reported by the API. The database name and prefix must therefore still match the GlobalID, or things (such as Pywikibot's interwikidata.py) break.

From https://www.mediawiki.org/wiki/Manual:Wiki_ID "The wiki ID (or database ID) is the most common way of identifying a wiki within a wiki farm in MediaWiki. When every wiki is in a separate database, it is simply the database name; when multiple wikis share a database and are differentiated with table prefixes, it is in the form <db name>-<table prefix>. It can be retrieved by calling wfWikiID()." Back in the days before Wikibase, no one external to the server much cared what the database was named internally. The database name might have been exposed as the prefix to a few cookies, overrideable by https://www.mediawiki.org/wiki/Manual:$wgCookiePrefix but otherwise didn't affect much of anything. Wikibase introduced the concept of a GlobalID (such as 'dewikivoyage' or 'enwiki') being publicly displayed every time an inter-language link was created on a Wikidata-style repository. The WikiID reported by the API was suddenly important, as the API was being queried in various places, including the Wikibase repository extension (when a new inter-language link is supplied by the user, to see if the page exists) and the Pywikibot extension (for functionality like interwikidata.py - which imports inter-language links). The presumption was that the WikiID matches the GlobalID matches the database name and prefix. Worse yet, the idea that the hard-coded global naming convention was a language code (such as 'pt') followed by a project name which began in 'wiki*' or 'wiktionary' ( see https://phabricator.wikimedia.org/T172076 ) might have made sense on Wikimedia's cluster (where the databases happened to have those names already) but almost always didn't match the existing database names on other, non-Wikimedia projects. There is a configuration setting in the Wikibase extension, $wgWBRepoSettings['localClientDatabases'][(...GlobalID...)]=...database name...; which does a translation from GlobalID to database name, but only within the Wikibase code and only in one direction (GlobalID to database name). There is no corresponding translation in the opposite direction - as that would have to be part of the API, which is core code. If my existing internal database names look like "myproject_xx" and "myproject_xx"y" for language xx: and xy: (which are not mutually intelligible) but the GlobalID's for the projects were xxmyproject and xymyproject (because Wikibase seems to be expecting everything to follow WMF-like naming conventions) then there's no way (at least in MW 1.31) to force the API to report the proper GlobalID short of changing includes/api/ApiQuerySiteinfo.php protected function appendGeneralInfo( $property ) to make the substitution (from MW1.31, insert after line 247): $wikiid = wfWikiID(); this kludge to report in the WikiID field the externally-known 'GlobalID' to ensure compatibility with interwikidata.py: if (substr($wikiid,0,9)=='myproject_') $wikiid=substr($wikiid,9) . 'myproject'; The only other alternative is to rename every existing database so that the database name is forced to be the externally-reported GlobalID. That's doable, but it seems a bit inconsistent that a translation table like $wgWBRepoSettings['localClientDatabases'][] exists in some portions of the code but not others. Effectively, the use of $wgWBRepoSettings['localClientDatabases'][] to match GlobalID's to dissimilar local database names does not work, as the underlying database name is still being externally reported by the API. The database name and prefix must therefore still match the GlobalID, or things (such as Pywikibot's interwikidata.py) break.