Page MenuHomePhabricator

Expose DBNAME in Lua Site library
Open, Needs TriagePublic

Description

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

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 26 2016, 8:01 AM
Anomie added a subscriber: Anomie.

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.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptSep 26 2016, 2:34 PM

I tend to agree with Anomie on this. I'm not sure this should be done.

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.

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.