Wikimedia Commons has been a WikibaseClient for several years now, accessing data from Wikidata, using entity IDs with no prefix, like Q64 and P31.
However, as Commons is becoming a WikibaseRepo in its own right to support SDC by running the WikibaseMediaInfo extension, the empty ID prefix will now conceptually refer to the local repo, that is, commons itself, so commons can use identifiers like M56789 to refer to MediaInfo entities.
There are essentially three options:
- Keep the "split brain" approach, an accept the fact that a wiki that acts as both, a repo and client, will have duplicate service instances, using separate and potentially inconsistent configuration. This is the status quo, and comes with the potential for subtle and hard to track bugs down the road.
- Consolidate the configuration and internal state of repo and client code (there is an old design document about this). In concrete terms, this means that there must be only one WikibaseServices instance, which implies that there is only one top level EntityRevisionLookup, only one underlying EntityNamespaceLookup, etc. This would mean that the empty entity prefix can only resolve to one repo, and on repos, the empty prefix would always refer to the local wiki. This would break all content on Commons that currently uses Q-IDs or P-IDs with no prefix. They would have to be migrated, by changing the relevant templates and modules, and cleaning up using a bot.
- Consolidate internal state and config, but introduce the concept of default repos per entity type. This way, the meaning of the empty prefix could depend on which type of entity is referenced, and Q12345 could be handled as equivalent to wd:Q12345, if wikidata is specified as the default repo for items. This could be done without much trouble by adding an additional mapping to MappingEntityIdParser.