Page MenuHomePhabricator

Inconsistent behavior of mw.wikibase.getDescription
Open, Needs TriagePublic

Description

Preamble

As described in the documentation, function mw.wikibase.getDescription returns an item's description from a Wikibase instance to the linked wiki page.

Problem

The returned text is parsed for wikicode like ''formatting'' or [[wikilink]], but it does not resolve templates, so a fragment like {{Some Template}} is returned like plain text.
It looks like this behavior is inconsistent: why parsing only part of the wikicode and not all?

Proposed solution

Depending on the design choice behind the mw.wikibase.getDescription function, all the text should be returned as raw, or the wikicode should be completely parsed and expanded.
Additionally, regardless the decision, the expected behavior of the function should be explained in the documentation for proper reference to programmers.

Event Timeline

I might be wrong or even misunderstanding the issue, but the description in wikibase shouldn't have any wikilinks nor templates. I don't know if that applies to formatting too, but wikilinks and templates would make them only useful for the wiki in which they were added and completely useless for third party users where even if they could format those links they can't know to which wiki they should be linking to.

This is not an "inconsistency" of mw.wikibase.getDescription, but of Scribunto itself (and I believe it's on purpose). Try the following:

local p = {}
function p.test()
    return "''formatting'' [[wikilink]] {{Some Template}}"
end
return p

I might be wrong or even misunderstanding the issue,

I think you got ir right :-)

but the description in wikibase shouldn't have any wikilinks nor templates. I don't know if that applies to formatting too,

I would say no for formatting: consider a description like This is a '''very''' important item: it is a meaningful formatting regardless the wiki it is written in.

but wikilinks and templates would make them only useful for the wiki in which they were added and completely useless for third party users

Not necessarily.
First of all consider the case where the proper name of a person is linked or a general concept: if an item is relevant for a certain wiki, likely the links within the description are as well.
Second, let's remember that Wikibase covers installations big and small: not all the instances are Wikidata: I believe there are several cases where Wikibase instance supports just a few wiki, or even one alone.
Third, predefined interwiki prefix might be used as well.

Anyway, my main point here is that there should be a consistent rationale (whatever it might be) behind the function's behavior and it should be clearly explained in the doc.

This is not an "inconsistency" of mw.wikibase.getDescription, but of Scribunto itself

Thanks, never noticed this

(and I believe it's on purpose).

Even if it's on purpose, IMHO it doesn't make completely sense because is treating similar wikicode in different ways.
In any case, even if it is decided that this is the correct behavior, it is necessary to properly document it.

(and I believe it's on purpose).

Even if it's on purpose, IMHO it doesn't make completely sense because is treating similar wikicode in different ways.
In any case, even if it is decided that this is the correct behavior, it is necessary to properly document it.

Extension:Scribunto/Lua reference manual § Returning text:

The module function should usually return a single string; whatever values are returned will be passed through tostring() and then concatenated with no separator. This string is incorporated into the wikitext as the result of the {{#invoke:}}.
At this point in the page parse, templates have already been expanded, parser functions and extension tags have already been processed, and pre-save transforms (e.g. signature tilde expansion and the pipe trick) have already happened. Therefore the module cannot use these features in its output text. For example, if a module returns "Hello, [[world]]! {{welcome}}", the page will read "Hello, world! {{welcome}}".

Therefore the module cannot use these features in its output text.

Given this statement, then this cannot be the explanation, because I made it work on my own wiki with some custom code.
First I take the output of mw.wikibase.getDescription() and then I run frame:expandTemplate on the template present in the text, searching for the {{…}}. So it's still possible to expand templates after getDescription returns.

I don’t think there’s any Wikibase issue here. Wikibase returns the description as plain text without modification; if you want to show it on the page, it’s your responsibility as the module author to escape it, probably by calling mw.text.nowiki() on it.

Your custom code is exactly the "workaround". Still, the explanation is principally correct, it simply says that if you return {{…}} from a module, it won't be expanded. But when you call frame:expandTemplate, you expand it yourself and don't return any {{…}} anymore. (There is an even easier and more evil way, using frame:preprocess.)

Your custom code is exactly the "workaround". Still, the explanation is principally correct, it simply says that if you return {{…}} from a module, it won't be expanded. But when you call frame:expandTemplate, you expand it yourself and don't return any {{…}} anymore. (There is an even easier and more evil way, using frame:preprocess.)

Thanks. The explanation on the manual was a little misleading, at least to me, and it was my understanding that, at the time of the function return, template expansion was not possible any longer at all.
I see now that the meaning was different.

I don’t think there’s any Wikibase issue here. Wikibase returns the description as plain text without modification; if you want to show it on the page, it’s your responsibility as the module author to escape it, probably by calling mw.text.nowiki() on it.

You are right, no Wikibase issue, I understand this now.
On the other hand, don't you think it's maybe worth to better explain this in the documentation? I mean, what I learnt in the current discussion is not exactly straightforward to someone approaching LUA coding with Wikibase library.
This behavior has nothing to do with Wikibase – I now understand – but I think at first sight it might seem to be Wikibase-related, so maybe the mechanism can be better explained in the documentation.