Help talk:TemplateData

Jump to navigation Jump to search

About this board

Previous discussion was archived at Help talk:TemplateData/Archive 1 on 2015-09-04.

"Syntax error in JSON" help link does not link to section with help in it

Jonesey95 (talkcontribs)

I recently tried to edit Template:Infobox country on en.WP. I made a minor fix to correct a typo, and I received an error message when I attempted to save: "Syntax error in JSON (help)". I subsequently noticed multiple problems:

1. I tried to save again, and the editor let me save the template.

2. I edited the template again to make another small fix, got the same error message, and was unable to save despite four or five attempts. Note that I was NOT trying to modify any JSON, about which I know almost nothing because I have found it to be poorly documented.

3. I clicked on the "help" link, and it took me to a page that did not have a section describing how to respond to this "Syntax error in JSON" message. Please create such a section, knowledgeable people.

4. I was finally able to deduce/guess that the problem was in the template's documentation, not in the template code, even though I was not editing the documentation. I happened upon the link to JSONlint and was able to fix the documentation, which then (apparently) allowed me to save the template.

5. I was able to re-edit the documentation to introduce invalid JSON, with no error message or complaint from MediaWiki:

Please apply the JSON error-checking code only to the page that contains the JSON formatting information, NOT to the template. At a minimum, please apply the JSON error-checking code to any page containing JSON code so that JSON-deficient/clueless editors such as myself do not get stuck when trying to make valid wikicode edits to template pages. Whoever introduces the invalid JSON code to the documentation should be prevented from saving, not the subsequent template editor.

Rant end. Thanks for reading.

Whatamidoing (WMF) (talkcontribs)
Mvolz (WMF) (talkcontribs)

Not entirely but I can shed some light; this is the result of a combination of several different issues.

One is that the PHP engine we use to validate JSON allows invalid JSON (duplicate keys, trailing commas) which I can't imagine will get fixed anytime soon since we aren't in the business of modifying PHP engines :/ This is the inconsistent behaviour noted in point 5, and was the reason you were able to save invalid JSON: task T128029

There is a task for having JSON in a separate namespace, high priority, that would also help fix this issue of people editing pages with JSON in it but not knowing enough to be able to fix errors in it, task T56140, but it was created in 2013 and no one is working on it as far as I know :/. A band-aid solution is to use transclusion and to have the JSON on a separate page, but this has to be done page by page so it's not a great solution.

As for the help link, I have added a small section about this issue to it here: Although it probably needs some work, and for translate tags to be added, and maybe we should link specifically to that section for that error instead of to the whole help page?

Jonesey95 (talkcontribs)

Item #2 above is the one that really bothered me. I don't know about JSON, I don't really care about JSON, and I wasn't editing a page with any JSON in its code. Nevertheless, I received a JSON error when trying to save code with no JSON in it. That should not happen. Thanks for listening.

Jdforrester (WMF) (talkcontribs)

and I wasn't editing a page with any JSON in its code

But, of course, you were. That's what template transclusion does, unfortunately. It's why it's an anti-pattern. :-(

Mvolz (WMF) (talkcontribs)

Just FYI but we've actually transitioned from HHVM to PHP7 now, which should make at least the problem of people saving invalid JSON because HHVM allowed it a bit better...

Reply to ""Syntax error in JSON" help link does not link to section with help in it"

Documenting Lua modules

Summary by
Adamw (talkcontribs)

Will TemplateData be used to document Lua? Can VisualEditor use TemplateData to give hints for module invocation?

Whatamidoing (WMF) (talkcontribs)

Are you meant to be invoking a module directly?

Adamw (talkcontribs)

Good point, thanks! There's already a /doc subpage (e.g. [1]) for the module itself, and that's all we need.

It's the functions within a module which can be invoked from wikitext, these take parameters, and this is where we would need the structured documentation. I'm not sure how we could provide these docs (or maybe editors feel this is not lacking?). LDoc and maybe other syntaxes would be appropriate for inlining docs in the source code, but wouldn't cover our use case. We pass an opaque frame and it's the args arguments within that define the module's MediaWiki interface. We also need a way to indicate which functions are meant to be public.

Needless to say, however we (if we) decide on a syntax, it should be machine-parsable so it can be leveraged by VisualEditor and other tools.

Reply to "Documenting Lua modules"

can a template count what order it is in a page?

Evolution and evolvability (talkcontribs)

Is there a way for a template to count how many copies of itself are above it in the page? It'd be interested to have an 'auto vaue' in v:template:fig that works out the |number=parameter automatically.

Reply to "can a template count what order it is in a page?"

"If you have made errors, it will not let you save."

Jonesey95 (talkcontribs) (talkcontribs)

Simple. Hacky unexpected usage results in unexpected behaviour and breakage.

Jonesey95 (talkcontribs)

Someone made an error, and the page was saved with the error, which appears to contradict the statement I quoted above. I believe that this page's documentation should be clarified.

Ivan Pozdeev (talkcontribs)

Judging by the tags on the edit, they edited raw wikitext of the page rather than using the specialized TemplateData editing tool. Thus their edit wasn't subject to its scrunity.

Jonesey95 (talkcontribs)

Thank you for the actual helpful answer! I have updated the page to reflect the difference between using the tool and using a wikitext editor. (talkcontribs)

That's the wrong answer. The hacky transclusion means that what's in the page is actually irrelevant. In fact the page content might have changed without any edit to the page.

That's clearly documented mediawiki behavior.

Jonesey95 (talkcontribs)

IP editor: Your explanation does not make sense to me. In the edit I linked above, an editor replaced the word "description" in the TemplateData code with the word "descriptiwon", which presumably caused the TemplateData error. I don't see any evidence of a "hacky transclusion" in that edit, but I might be missing something. If you have a better explanation that answers my original question, feel free to edit this Help page to clarify it. Thanks. (talkcontribs)

Err... The expected use of this extension is directly embedding the templatedata tag to the page. All templates or lua modules that override that behaviour are clear hacks( Also you're wrong about the change, template transclusions were also added.

Perhaps you have an incomplete understanding of how templates work. Templates are entirely free to fully ignore all parameters used to call it. Or to parse them differently and output something different from the input.

So what was input was not necessarily what was output by the template. That coupled with the hacky use results in unexpected behaviour.

It will only be possible to fully prevent bad saves if/ when templatedata is moved to its own page like .CSS,.js and lua modules.

Jonesey95 (talkcontribs)

The last bit is something that you and I can firmly agree on. Storing programming code such as Template Data in an unprotected page that was designed to store template documentation is simply bad programming practice. I look forward to Template Data being moved to its own set of pages, which is something that should have happened long ago.

Ivan Pozdeev (talkcontribs)

Raw text editing is much simpler and has more flexibility than any custom tools, and the errors are very visible and easily fixable.

It also allows for easy experimentation with new features, before a custom toolset is updated or even without the need to build one in the first place -- which is a dramatic time and effort saver.

Due to the above, the ability to edit raw data is seen as a strength of a wiki rather than a drawback.

The maximum use I see for encorcing syntactic correctness is to run a syntax checker before saving -- and again, it can only produce a warning rather than a hard error because there's a possibility that the user is trying something that the syntax checker doesn't know about.

Jdforrester (WMF) (talkcontribs)

I'd estimate that it would cost roughly US$250k of staff time to move TemplateData into an MCR slot now; most of that cost would be in making a lot of decisions about how MCR would operate, rather than specific to TemplateData itself. I don't think there's appetite for that right now, sorry.

Jonesey95 (talkcontribs)

As someone who donates roughly US$100K worth of volunteer time to en.WP every year, this answer leaves me a little cold. Discussing the cost of fixing a suboptimal programming decision is probably not the best approach to take with the volunteers who are left to deal with the consequences of that decision.

Jdforrester (WMF) (talkcontribs)

It wasn't a "decision". TemplateData (created in 2012–13) did not use MCR slots (created in 2017–2022) due to the polarity of time.

Yes, in retrospect, we could have foreseen this abuse and held up eight years of development, but all things must be weighed against each other. Similarly, the decision to create the #tag hack (made in ~2008) is the root cause of a lot of problems here, but it was also vital in helping editing communities establish things they felt that they needed at the time.

If you think that this is an important issue and worth the expenditure, I would encourage you to make your views known to the people that make decisions on this, but the people trying to help you on here aren't any of them, sorry.

Whatamidoing (WMF) (talkcontribs)

I wonder whether the error-checking mechanism is looking for typos, or looking for valid JSON formatting. I'm guessing that it's the latter.

Jdforrester (WMF) (talkcontribs)

It's looking for schema compliance. So valid JSON, and valid against the TemplateData specification.

Reply to ""If you have made errors, it will not let you save.""

Visual Editor not pulling over TemplateData

Brickscrap (talkcontribs)

When editing a page with Visual Editor using a Template with TemplateData, it's not pulling across the TemplateData. Is it possible I've missed a configuration setting?

Whatamidoing (WMF) (talkcontribs)

Well, maybe. On the public wikis (like Wikipedia), the problem is usually the overworked job queue, so the first thing that I'd suggest is that you try making a null edit to the template's page. Just open the page in a wikitext editor, make no changes, do not add an edit summary, and click the Save/Publish button anyway.

If that doesn't solve the problem, then it'd be helpful to know whether the TemplateData is on the Template: page itself (like Template:Information) or on a sub-page (like Template:Information/doc).

Reply to "Visual Editor not pulling over TemplateData"

Missing "inherits" option

Summary by Whatamidoing (WMF)
Fringio (talkcontribs)

Since TemplateData allows the use of the "inherits" field, the TemplateData editor should have a field where the user can set a "parent" parameter for the "inherits" field.

Whatamidoing (WMF) (talkcontribs)
Mvolz (WMF) (talkcontribs)

I think the editing team as a whole is the maintainer, but I've never contributed to it.

Reply to "Missing "inherits" option"
Zackmann08 (talkcontribs)

Is there any way to edit this information basically in a spreadsheet? It would just be really nice to basically go down the list updating fields. So I know that I want to set the type for fields. Rather than opening each param individually and setting the type, I could just work my way down the rows setting the values. Even an option to export/import to a CSV would be wonderful!

Ivan Pozdeev (talkcontribs)

You can edit the source XML with whatever tool you're comfortable with.

XML is a tree, not a table btw, so a spreadsheet is not applicable to it in the general case. (talkcontribs)

Templatedata isn't xml, it is stored in json.The trouble is that it is quite hard to illustrate something like a spreadsheet when it is more like a tree based. Although there are some json editors that try to do tat to an extent.

Whatamidoing (WMF) (talkcontribs)
Reply to "Editing in table format"
NemesisAT (talkcontribs)

I'm just trying out this extension on my wiki, is there support for letting a user pick pre-defined options for a parameter?

Thanks in advance

Whatamidoing (WMF) (talkcontribs)

No, this feature doesn't exist right now, but I believe that it's being considered for the future.

NemesisAT (talkcontribs)

Ah okay, thank you

Reply to "Choose parameter from a drop down?"
Cavila (talkcontribs)

How do we enable the editor? I'm not seeing anything so perhaps it relies on Visual Editor and this article is somehow assuming you've installed VE?

Samwilson (talkcontribs)

Do you mean an editor for the TemplateData definitions, or for the actual templates? The latter is indeed part of VE (and there's a project underway to provide a similar thing for the normal wikitext editor).

Cavila (talkcontribs)
Reply to "TemplateData editor?"

Template documentation editor should warn about duplicate parameter names

Summary last edited by Elitre (WMF) 18:02, 14 February 2018 1 year ago
Kaartic (talkcontribs)

When trying to edit parameters that already exist, the template description editor, must warn the editor in case any other parameter with new name already exists. Instead it seems to append numbers to the name which could go unnoticed.

Steps to reproduce

  • Go to Template:Em page
  • Edit the page and invoke the Template documentation editor using Manage TemplateData
  • Edit a template parameter which has the name title and change it's name to style

Expected results

Warning is displayed to the user about an already existing parameter with the same name.

Actual results

An integer is appended to the new name (e.g. style0). It could go unnoticed to the editor.

It could and has. See the infobox for the Fabergé eggs, which has a duplicate "width", once for the width of the egg and once for the image of the egg, which conflict. KDS4444 (talk) 13:48, 2 May 2017 (UTC)