Create component for $wgDBname in mw.site.
Rationale:
When providing Lua modules for multiple wiki projects, local adaptions should be supported easily. Based on a short DB name the appropriate adjustments need to be accessed.
Currently there is available only a mw.site.server field.
This requires
if mw.site.server == "//de.wikipedia.org" or
mw.site.server == "//de.wikipedia.beta.wmflabs.org" then
site = "dewiki"
end| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T50176 Requested Scribunto/Lua built-in methods/functions (tracking) | ||
| Open | None | T146616 Expose DBNAME in Lua Site library |
Local adaptations would probably be better done with a configuration data-module rather than code branching on the identity of the current site.
IMO it would be more sensible to provide mw.site.wikiid as wfWikiId(), rather than $wgDBname.
Some wikiid or wikiId rather than traditional dbname would be fine with me.
The concept of local config modules is understood, as you might see here or here or here.
However, local configs require local people and even sysops to maintain a software configuration theirselves. I know many wiks that are not able to do this with local software experts, asking e.g. German Wikipedia for support. They would have to adapt each new feature locally.
A config scenario might be shared on a larger number of wikis, with exceptions for only a few ones, like e.g. Commons. Then global maintenance of a few standard groups of different profiles provides a more robust behaviour and will share all updates, and adaptions are performed by some global experts. Might be combined and overruled by local config modules anyway.
This seems like a non sequitur. None of this is improved by being able to automatically switch by wiki ID, since the different configurations for different wiki IDs would have to be written anyway (just in a different place). And centralized modules are also totally orthogonal to this.