Given that I want to create a json page in the Module namespace

Why is that a given? I'm inclined to decline this task since it starts from a faulty premise.

It is acceptable to create the page in the user space and then move the page into the module space. It will retain the correct content model, even after editing the page.

Allowing moving non-Scribunto content into Scribunto's namespace is arguably a bug in itself.

In T144475#2601513, @Anomie wrote:

Given that I want to create a json page in the Module namespace

Why is that a given? I'm inclined to decline this task since it starts from a faulty premise.

A namespace isn't a content model, it is a group of pages with certain similar features. It is "code", and because of the implementation of loadData() also "codified data", and thus also json. To interprete "Module" as "lua" would lead to a large number of namespaces if we want to add other languages.

It is acceptable to create the page in the user space and then move the page into the module space. It will retain the correct content model, even after editing the page.

Allowing moving non-Scribunto content into Scribunto's namespace is arguably a bug in itself.

No its not, Scribunto should simply handle something that is "lua", and create the page with correct content model, and put the page into whatever namespace the site assigns to such content.

Good arguments are always appreciated.

In T144475#4894255, @jeblad wrote:

This is closed for a wrong reason, and blocks proper localization by using json files. It also blocks use of json-based configuration files, forcing such files into other non-related namespaces.

I don't understand this point. We have loadData, which pulls information from a 'static' Lua table or table of tables (i.e. localization, configuration), so it could be used the same way as a Json configuration file, and so doesn't "force such files into other non-related namespaces".

What use case are you actually trying to enable?

I happen to agree with the gist of this task, but I think a reasonable 'fix' to it would be T85847: Grant editcontentmodel right to all logged in users.

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

In T144475#4894377, @Izno wrote:

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

In part, that is an issue of interoperation of two different extensions while this is proposing added behavior to Scribunto. And in particular that one came at it from the perspective of TemplateStyles rather than Scribunto.

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

In T144475#4894427, @Anomie wrote:

In T144475#4894377, @Izno wrote:

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

In part, that is an issue of interoperation of two different extensions while this is proposing added behavior to Scribunto. And in particular that one came at it from the perspective of TemplateStyles rather than Scribunto.

Okay.

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

There's a use case that Nihiltres was looking at a year or two ago to sync WikiProject colors and names and such for both the metadata gadget as well as WikiProject banners. The gadget of course would like to consume json or something friendly for Javascript; the module behind WikiProject banners would also like to have the color scheme conveniently located. Discussion was at Template talk:WPBannerMeta. I would guess there are other use cases that are similar in that we want one place to store data, not multiple, but more rare than not, and in that specific case, the Json would live as a (sub)page of a particular WikiProject banner in the Template namespace.

Sharing of configurations is an obvious case, reusing localization is another (importing into Mediawiki-space is not always a good idea), and importing data to be reused by Lua scripts.

In T144475#4894433, @Izno wrote:

In T144475#4894427, @Anomie wrote:

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

There's a use case that Nihiltres was looking at a year or two ago to sync WikiProject colors and names and such for both the metadata gadget as well as WikiProject banners. The gadget of course would like to consume json or something friendly for Javascript; the module behind WikiProject banners would also like to have the color scheme conveniently located. Discussion was at Template talk:WPBannerMeta. I would guess there are other use cases that are similar in that we want one place to store data, not multiple, but more rare than not, and in that specific case, the Json would live as a (sub)page of a particular WikiProject banner in the Template namespace.

FWIW, it's already possible to parse JSON in Lua by using https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.text.jsonDecode

If the main advantage of mw.loadData() is that it is only parsed once, could you write a wrapper Lua module that parses the JSON and returns a Lua table for loadData?

In T144475#4897944, @Legoktm wrote:

FWIW, it's already possible to parse JSON in Lua by using https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.text.jsonDecode

I knew this as I was making my commentary; your comment is a bit tangential, but perhaps we can say that we already have basic level of support in Scribunto and this task would better support JSON. One way to do that for all extensions in this case would be to figure out who other than admin should be able to change the content model of a page, but that's already a different task already linked upward in the page.

If the main advantage of mw.loadData() is that it is only parsed once, could you write a wrapper Lua module that parses the JSON and returns a Lua table for loadData?

I'd actually would like to see a loadJsonData in the library with the same loading characteristics as loadData, as at least one other editor would have liked to store his data in JSON rather than Lua, but I think that's a separate task.

Bits and pieces of JSON is available, some documented, some not. It is pretty weird.

Related: T226926: Investigate separate user right for creating pages with custom content models

In T144475#4894427, @Anomie wrote:

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

Another use case not yet mentioned is maintaining data by bots. There are libraries or built-in functions for nearly any programming language that can produce JSON, but there are hardly if any such that could produce Lua code, so bot authors need to write their own Lua code producers. This reinvents the wheel and it’s easy to get it wrong (did you remember to escape everything? what about 0/1-based indexing? etc.).

In T144475#4897945, @Legoktm wrote:

If the main advantage of mw.loadData() is that it is only parsed once, could you write a wrapper Lua module that parses the JSON and returns a Lua table for loadData?

The problem with this is that those wrapper Lua modules would need to be created for every JSON configuration, since Lua modules to be loaded with mw.loadData() cannot return dynamic things like a function that loads whatever JSON object the caller wants. Creating a JSON configuration and a Lua wrapper per WikiProject is only slightly better than creating a JSON configuration and a Lua configuration.

Change 833989 had a related patch set uploaded (by Legoktm; author: Legoktm):

[mediawiki/extensions/Scribunto@master] Allow creating JSON pages in the Module namespace

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

Change 833989 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@master] Simplify creating JSON pages in the Module namespace

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

Change 854075 had a related patch set uploaded (by Brian Wolff; author: Legoktm):

[mediawiki/extensions/Scribunto@REL1_39] Simplify creating JSON pages in the Module namespace

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

Change 854075 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@REL1_39] Simplify creating JSON pages in the Module namespace

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