Page MenuHomePhabricator

Add a property "talkNsText" to mw.title objects
Closed, ResolvedPublic

Description

A talkNsText property would nicely complement the already existing subjectNsText property.
See: https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Title_objects

If there is no associated talk namespace, just gives nil (as the talkPageTitle property, and the talk property of the namespace data, do).

Use case: in a module I currently have to do:

local namespace = mw.site.namespaces[page.namespace]
if namespace.talk then
    namespace = namespace.talk
end
local prefixedBase = namespace.name .. ':' .. base

With this property, I could do:

local prefixedBase = (page.talkNsText or page.nsText) .. ':' .. base

(edit: not until T369784 is fixed)

Event Timeline

Change 392309 had a related patch set uploaded (by Gerrit Patch Uploader; owner: Vlakoff):
[mediawiki/extensions/Scribunto@master] Add a property "talkNsText" to mw.title objects

https://gerrit.wikimedia.org/r/392309

@Reedy Indeed. My first patch was:

data.canTalk = ns.talk ~= nil

if ns.talk ~= nil then
	data.talkNsText = ns.talk.name
end

I updated it to the clearer:

if ns.talk ~= nil then
	data.canTalk = true
	data.talkNsText = ns.talk.name
else
	data.canTalk = false
end

As pointed out in these comments, when there is an interwiki, the Scribunto Title objects give some erroneous results, which in turn affects the results of the "talkNsText" feature I was implementing here.

Before starting, this code just to show the interwiki is validated and has to exist:

mw.title.makeTitle( 'Module', 'TestFramework', nil, 'interwiki' ).isExternal -- false
mw.title.makeTitle( 'Module', 'TestFramework', nil, 'en' ).isExternal        -- true
mw.title.makeTitle( 'Module', 'TestFramework', nil, 'commons' ).isExternal   -- true

I will be using mw.title.makeTitle() which requires to explicitly provide the namespace and interwiki, contrarily to mw.title.new() which rely on parsing by the underlying PHP Title class. As we explicitly provide the namespace and interwiki, we should expect them to be working.

mw.title.makeTitle( 'Module', 'TestFramework', nil, 'en' ).subjectNsText -- gives '', expected 'Module'
mw.title.makeTitle( 'Module', 'TestFramework', nil, 'en' ).isContentPage -- gives true, expected false

mw.title.makeTitle( 'Module', 'TestFramework', nil, 'en' ).subpageText   -- gives 'Module:TestFramework', expected 'TestFramework'
mw.title.makeTitle( 'Module', 'Test/Framework', nil, 'en' ).subpageText  -- gives 'Module:Test/Framework', expected 'Framework'
mw.title.makeTitle( 'Module', 'Test/Frame/work', nil, 'en' ).subpageText -- gives 'Module:Test/Frame/work', expected 'work'

Basically, it considers the page to be in the main namespace, with the rest being the base page title (remember there are no subpages in the main namespace).

This seems to be a limitation of the underlying MediaWiki Title class, which apparently doesn't support interwikis by design.

Additionally, a foreign wiki doesn't forcibly have the same namespace structure as the current wiki. (associated talk namespace, subpages enabled…)

Basically, all properties that relies on the wrongly set ns variable in function makeTitleObject() are affected.

This might be improved in mw.title.makeTitle() as the namespace is explicitly passed, contrarily to mw.title.new() that relies entirely on the parsing by the Title class. But it would introduce discrepancy between the two functions. And remains the fact that the foreign wiki may have a different namespace structure.

It would make sense to set the uncertain properties to nil, as they are unknown actually, rather than to values that are often erroneous. But it could break existing calling code.

So, what can we do?

Change 392309 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@master] Add a property "talkNsText" to mw.title objects

https://gerrit.wikimedia.org/r/392309

Od1n updated the task description. (Show Details)

On a related note, in TitleLibraryTests.lua there are tests for subjectNsText, and now for talkNsText as well, but there are no tests for nsText.