Page MenuHomePhabricator

Magic word variable for content model {{CONTENTMODEL}}
Open, LowPublicFeature

Authored By
Bugreporter2
Jan 30 2023, 8:11 AM
Referenced Files
F57731445: image.png
Nov 22 2024, 10:57 AM
F57731438: image.png
Nov 22 2024, 10:57 AM
F57731433: image.png
Nov 22 2024, 10:57 AM
Tokens
"Like" token, awarded by Pppery."Like" token, awarded by Bugreporter2.

Description

Feature summary

There should be a Extension:ParserFunctions variable for the content model of a page.
Suggest {{CONTENTMODEL}} and {{CONTENTMODELE}}.

A standard Wikitext page would return Wikitext. Other content types could not return the variable within the page itself, but this variable could be used in wikitext-based system messages; so a JavaScript page returns JavaScript, a CSS page returns CSS, etc. This info can be used to trigger switches.

This would not affect caching, given that content model changes are rare.

Event Timeline

@Bugreporter2 Could you please give a example on how this could be used?

Examples of the system messages I mentioned earlier would include, for example:

[[Mediawiki:editinginterface]] which could be changed depending on content model. For example 'you are editing a CSS page, etc'

Another one: [[Mediawiki:ns-tab]] could say something different for different content models, like 'user CSS page'.

Or [[Mediawiki: sitenotice]] could display something based on content model. [[Mediawiki:copyrights]] can also be used as a page-bottom general element, with switches (I know it's not intended as such, but it can be used that way).

There is also the potential for its use in things like custom toolbars, if and when that happens, and they are wikitext-based. Just one extra building block towards that.

Some notes:

"Magic Variables" are defined in <code>\includes\parser\CoreMagicVariables.php</code>

The following lines of code need to be added to an appropriate place. The second one with the e on the end is to return <code>plain_text</code> (with an underscore) rather than <code>plain text</code> (with a space character):

<pre>

			case 'contentmodel':
			case 'contentmodele':

</pre>

There is an array called <code>$wgContentHandlers</code> which should contain these four values:

<pre>
CONTENT_MODEL_CSS
CONTENT_MODEL_JSON
CONTENT_MODEL_UNKNOWN
CONTENT_MODEL_WIKITEXT
</pre>

And may have others added to it; in particular there's one for "Sanitized CSS" and possibly another one called JavaScript (though JSON=JavaScript, potentially. It's confusing.)

Now then, if matches, then output...

Does this help anyone?

Bugreporter2 renamed this task from ParserFunctions variable for content model to Magic word variable for content model {{CONTENTMODEL}}.Nov 7 2023, 7:07 AM
Aklapper lowered the priority of this task from Medium to Low.Nov 14 2023, 8:59 AM

@Bugreporter2: A good first task is a self-contained, non-controversial task with a clear approach. It should be well-described with pointers to help a completely new contributor. Given the current short task description I'm removing the good first task tag. Please add details what exactly has to happen where and how for a new contributor, and then add back the good first task project tag. Thanks a lot in advance!

Some notes:

"Magic Variables" are defined in <code>\includes\parser\CoreMagicVariables.php</code>

This is a file in MW core, yet this task has the ParserFunctions tag, which is for the extension. I don't think this magic word makes a lot of sense in Extension:ParserFunctions, in my opinion this task should have some tag for MW Core instead.

Yes, I think you are right @SomeRandomDeveloper I have updated the task description.

I still think this is a straightforward task that is a suitable "first task." Are you interested in taking on the challenge?

image.png (365×978 px, 61 KB)

image.png (263×995 px, 36 KB)

Managed to add the magic word. Since there are no content model names in core that need to be url-encoded, I switched my language to a different one with characters that actually need to be encoded to test it:

image.png (139×967 px, 29 KB)

Change #1094385 had a related patch set uploaded (by SomeRandomDeveloper; author: SomeRandomDeveloper):

[mediawiki/core@master] Add {{CONTENTMODEL}} and {{CONTENTMODELE}} magic words

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

Content model is available via Lua. I don't see a point in this proliferation of magic words which we should be moving away from. Gerrit patch even includes some discussion on four new magic words – CONTENTMODEL, CONTEMODELE, CONTENTMODELID, CONTENTMODELIDE – which is the exactly the kind of madness prevented by using Lua which provides a structured and intuitive way to access such data.

Content model is available via Lua. I don't see a point in this proliferation of magic words which we should be moving away from. Gerrit patch even includes some discussion on four new magic words – CONTENTMODEL, CONTEMODELE, CONTENTMODELID, CONTENTMODELIDE – which is the exactly the kind of madness prevented by using Lua which provides a structured and intuitive way to access such data.

{{CONTENTMODELIDE}} would be redundant, as discussed on Gerrit.
Scribunto seems to provide the content model id ("Scribunto", "wikitext", "css", "javascript") but not the translated version, which would primarily be useful for non-English languages which use different words/characters. If you'd want to display the current content model e.g. in a system message as shown in T328254#10347646, you'd need to have a scribunto module that provides a translated version for the id of each content model. So in my opinion while whether we need {{CONTENTMODELID}} (which is currently not included in the patchset) is debatable, {{CONTENTMODEL}} and {{CONTENTMODELE}} would be useful and more simple than having hardcoded translations in a lua module. I also don't think it's a good idea to execute lua for system messages like Mediawiki:Editinginterface due to the overhead it produces.

While it seems there's no cleaner way, it can be done without hardcoding translations, by reading the i18n message content-model-$model where $model is the lowercased model id (T358341). For example, mw.message.new('content-model-' .. string.lower( mw.title.getCurrentTitle().contentModel ) ):plain().

I also don't think it's a good idea to execute lua for system messages like Mediawiki:Editinginterface due to the overhead it produces.

Do you have any profiling that indicates this is a problem?

While it seems there's no cleaner way, it can be done without hardcoding translations, by reading the i18n message content-model-$model where $model is the lowercased model id (T358341). For example, mw.message.new('content-model-' .. string.lower( mw.title.getCurrentTitle().contentModel ) ):plain().

You could apply this to many other magic words like {{FULLPAGENAME}}, {{NAMESPACE}} and a lot more, yet those exist and are used over their lua equivalent as well.

Do you have any profiling that indicates this is a problem?

Not directly, this is stated at https://en.wikibooks.org/wiki/Scribunto:_An_Introduction/When_to_convert_a_template (which was written by someone who had created a ton of modules for wikipedia). Also considering that scribunto uses the same function to get the content model and the value first has to go through lua before it is printed out it would not make a lot of sense to be faster.

Those magic words predate the creation of Scribunto.

I didn't mean to say that Lua will be faster, just that a negligible loss of performance doesn't seem to warrant the costs of adding new magic words.

Good comments and interesting discussion.

I understand the argument for using Lua. I think the best thing to do is to get some implementation of this that works. So, an implementation of this via a template at https://en.wikipedia.org/wiki/Template:CONTENTMODEL referencing https://en.wikipedia.org/wiki/Module:Content_model would likely work equally well in practice as the magic word solution.

The main argument against this is that Lua is not part of MediaWiki Core, and some third party wikis might not have Lua installed, or enabled, because reasons. And if it's not included, should references to a template be included in the standard system messages? I would suggest probably not. As it is, third party wikis have to spend time copy-pasting a lot of modules and templates to get the same functionality as Wikipedia takes for granted.

And also someone would need to write the template and module, if you go down that route.