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.

Pols12 (talkcontribs)

Hello MacFan4000,

You have split several paragraphs in order to reduce translate tag use. I think this is a bad idea because this make the text harder to read. Indeed, those one-sentence paragraphs are really strange; beside this make some sections (especially introduction) very big. Would you see any inconvenience to come back to previous paragraph splitting?

Pppery (talkcontribs)

I agree. Having slightly cleaner wikitext is not worth having a significantly less clean rendered output.

Ата (talkcontribs)

It is actually possible to split a paragraph into two translatable units without visual differences on the page.

Reply to "Paragraph splitting"

Set default value to the value of another template parameter

GoodMagician (talkcontribs)

In a template the default value of a parameter can be set to the value of another parameter. For example, parameter 2 can default to the value of parameter 1...


What is the correct way to represent this relationship in templatedata so that Visual Editor will handle the default properly? I've tried the approach below, but instead of showing the value of parameter 1 the template shows the number 1.

# This approach results in the wrong default behavior 
# when the template is added with Visual Editor

  "params": {
    "1": {…},
    "2": {
      "label": "optional value",
      "description": "if this value is empty, show the value of parameter 1 instead",
      "suggested": true,      
      "default": "{{{1}}}"
    "paramOrder": […],
    "format": "inline"

Clump (talkcontribs)

My interpretation would be to indicate it as an alias.

Jonesey95 (talkcontribs)

Agreed. In the code shown above, 2= is an alias of 1=.

Tacsipacsi (talkcontribs)

However, there are situations where an alias doesn’t work. Imagine a template that links to the English Wikipedia. Its code is

[[w:{{{1}}}|{{{2|{{{1}}} }}}]]

—the first parameter (the article title) is required, while the second (the display text) is optional, and defaults to the article title. The two are clearly not aliases, but the default of parameter 2 is parameter 1. I usually write something like “parameter #1” to default and hope that the human reading it will understand what’s going on. Or describe the situation in description, and leave default empty. But neither of these workarounds is really a solution. Probably there should be a new key (mutually exclusive with default) that contains a parameter name (instead of literal text) the parameter defaults to. Support for this should be implemented in consumers like VisualEditor afterwards, of course.

Reply to "Set default value to the value of another template parameter"

"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.""

What's the convention to set a default value?

Summary by Cyberkagami

Template:If then show works great, thanks!

Cyberkagami (talkcontribs)

Since the template data does not have any functional feature to actually set it, I wonder what's the convention to set one.

I was using {{{param|defaultvalue}}} syntax, but this doesn't work well if the param is marked as "Suggested" because then the visual editor defines it as an empty string and thus shadows the default value.

{{#if:{{{param|}}}|{{{param}}}|defaultvalue}} does work, but is this really a convention? What do others do?

FeRDNYC (talkcontribs)

On Wikipedia there's Template:If then show, which slightly simplifies the syntax for doing exactly the same thing as your {{#if:...}} version, e.g.:

{{If then show|{{{param|}}}|defaultvalue}}

Jonesey95 (talkcontribs)

Search this Help page for "default" and "autovalue". One of those may be what you want.

Tacsipacsi (talkcontribs)

@Cyberkagami: Yes, {{#if:{{{param|}}}|{{{param}}}|defaultvalue}} is a convention. It not only helps with VisualEditor and TemplateData, but also makes possible to create copy-pastable “skeletons” in old-fashioned template documentation, like this one:

{{Infobox foo
|param = 
|bar   = 
|baz   = 

which would also be broken by the {{{param|defaultvalue}}} syntax if unused parameters are not entirely removed.

BoldLuis (talkcontribs)

I think it is time to give up the draft label and become to a reality.

All templates must include template date by default when created (later one can fulfill more in detail the fields, but a TemplateDate must be automatically created when the template is created.

Shirayuki (talkcontribs)
BoldLuis (talkcontribs)
Reply to "Time to give up draft"

Position of TemplateData code within page

PerfektesChaos (talkcontribs)

On “Adding TemplateData manually” it reads currently as: “but convention says that you add it at the bottom”

  • That is a particular custom in English Wikipedia.
  • In German Wikipedia, TemplateData should be arranged on top, since it is used for both general advice (with markup) and machine-readable exported information. The basic template description of TemplateData is simultaneously the introduction section of the template documentation page. Please see de:Template:Internetquelle as an example, and compare with a transclusion attempt.
Jonesey95 (talkcontribs)

I have modified the text in that section to recommend checking the local preference on your language's Wikipedia.

BoldLuis (talkcontribs)

It looks like reasonable. It can appear in the top of the page collapsed. I think all Wikipedias must follow the same principles. If not, this is a chaos.

Reply to "Position of TemplateData code within page"

Contradictory information on whether to translate

AttemptToCallNil (talkcontribs)

This article has two notices, one saying it's a draft, and the other warning people not to mark it for translation (internally called "DoNotTranslate"). The article is also marked for translation and has a number of translations started (although most don't have that much work done, and none has translated over a third of the messages).

Should translators refrain from translating this article? Should the DoNotTranslate notice be removed? Is there a massive rewrite of the article planned or in progress, and the translation markup with translations are from an obsolete version?

FeRDNYC (talkcontribs)

I'm just trying to understand where the contradictory information comes in. The page has two notices, yes, both of which say that it's a draft. The second notes that, therefore, it should not currently be translated. No contradiction there.

Is the issue that the automatic "Translate this page" message is still being shown, in addition to the notices? I mean, my take from that would be, specifically because that message is automatically shown, the Template:DoNotTranslate message is placed to override (rather than contradict) the automatic translation call-to-action.

But if that's seen as confusing, would it help if Template:DoNotTranslate also included instructions to ignore the existing translation data/message (if any)?

AttemptToCallNil (talkcontribs)

Or, yes, I could check the page's history. I see the notices were added very recently, and apparently, my guess of a rewrite was accurate. However, I should note the wording of the DoNotTranslate notice looks somewhat misleading in this situation.

Shirayuki (talkcontribs)
AttemptToCallNil (talkcontribs)

I appreciate the suggestion, but I don't feel comfortable just changing a template to support a specific case (a previously marked page with a rewrite in progress that should temporarily not be marked again) because I can't be confident I won't cause unintended bad consequences for other use cases.

FeRDNYC (talkcontribs)

That's really not that specific a use case. When pretty much any already-published page is marked as draft / currently undergoing rewrites, if it has existing translation data (which a lot of them will), it would fall into the same category. This would be a relatively common occurrence, in places where the (relatively-uncommon) Template::DoNotTranslate message is used. If it needs to be clarified, it should be.

Shirayuki (talkcontribs)

The page looks a draft, so it should not be marked for translation at this time.

By a massive rewrite, many translation units will be invalidated on marking for translation.

AttemptToCallNil (talkcontribs)

Thank you for this clarification. I guess I will refrain from translating this article for now.

Ата (talkcontribs)

@Shirayuki Last edits on the page were in March; do you plan or know if anyone plans to continue writing this page?

Shirayuki (talkcontribs)
Reply to "Contradictory information on whether to translate"
TheGEICOgecko (talkcontribs)

I've recently realized a problem in which Visual Editor keeps adding additional speces to every single field when I edit one. This is an example:

| streetaddress           = 154 Warren C Coleman Blvd N
| city                    = Concord
| state                   = North Carolina
| province                = 
| country                 = United States
| coordinates             = 
| type                    = Private co-educational elementary & secondary
| established             = 1976

I've been told that the problem is a hidden "format" code within Visual Editor's TemplateData programming code for a template, or something that. If this is true, what does that mean exactly, and should I be concerned with removing it, or is it OK? I don't see the problem with the field values aligning, but I've recieved a complaint, and I just want to make sure that either it's acceptable for my VisualEditor to format the infobox like this, or that I fix it so it doesn't format it differently from what is acceptable.

Whatamidoing (WMF) (talkcontribs)

This format was selected at, which contains a line that says "format": "{{_\n | _______________________ = _\n}}",

The visual editor doesn't change the article "line by line". It changes it "thing by thing". So if you edit a template (any template), the old version of the whole thing gets removed, and the new version of the whole thing gets inserted. The new version will always use the formatting specified for the template (which is either the single-line default (like {{fact|date=April 2020}}), or whatever is chosen for that template (which is what happens here; most infoboxes contain this code or something very similar). There is no way to make it figure out what the formatting style was for the old version of this template on this page and stick to that.

So theoretically, you could remove this code, or swap in a formatting code that matches the one article where someone complained, but then all the articles that use this formatting would get changed the next time you edited their infoboxes. Unless most of them use a different (but matching each other) whitespace style, it might be better to leave well enough alone.

should updating the TemplateData request a page marked as to be translated ?

Summary by Wladek92

done; solved creating a subpage.

Wladek92 (talkcontribs)

if I want to modify a FR string in the template data of a translatable template (ex: Template:Archived_extension, I do that opening the root version of the page in english. But this lead to flag this page has been modified and is good for new translation. This has 2 consequences : 1. there is nothing more to translate impacts other languages which have nothing to do.

Am I wrong ?

Christian FR (talk) 11:11, 31 March 2020 (UTC)

Wladek92 (talkcontribs)
Tacsipacsi (talkcontribs)

I think Shirayuki’s solution is probably the best one. IMO it’s a feature that the page has to be marked for translation after all changes, even if they don’t affect actual translatable text—changing sometimes several dozens of translations can cause considerable disruption if it’s done by an inexperienced user (or a vandal), and it also takes up server resources to update all translations (these updates also pollute recent changes). Given that, moving not translated parts to a subpage looks a quite good solution (using a subpage also causes that there’s no need to reparse all pages that use the template).

Wladek92 (talkcontribs)

Thanks, I agree 100%.

options to select from wikidata-item-name? wiki-page-in-category-name? non-local-wiki-page-name?

Evolution and evolvability (talkcontribs)

There are options to pick from lists of local wiki pages/templates/users. We can also pick from commons files. Extremely useful would be to be able to pick from lists of:

  • wikidata items.
  • wiki pages within a certain category
  • wiki pages at a different wiki
FeRDNYC (talkcontribs)

The wikidata request is already tracked in task T69659.

As far as the other two, I don't see anything tracking them. They use the wiki-page-name type, and as @Krinkle says in task T88900 (a similar request to expand the field to specifically target pages in the Template namespace):

Types don't take parameters

In other words, the field accepts a certain type of data: A page name. And it can (using the wiki page database) validate that the data entered is, in fact, a page name. But,

  1. It can't be told to accept only certain specific page names (like "pages in category N"), and
  2. There's no way to validate the data as a page name at a different wiki, since it's not in the local database. (Commons files are a special case, since that's a different data type and the database does, AIUI, contain a list of available commons files.)

Still, in that same comment Krinkle did mention the possibility of adding Category as a type, which perhaps could work in concert with the the wiki-page-name field to limit the available pages. (The external-wiki thing, I'm less optimistic about, but any sort of informed statement on its feasibility would have to come from someone with better technical knowledge of the system.)

FeRDNYC (talkcontribs)

Actually, now that I think about it the "selector" functionality (a pop-up list of page names, for example) is more a Visual Editor feature than a TemplateData feature, since TemplateData only deals with validation and typing.

But if a Category type were added to TemplateData, and a TemplateData form had a field with that type that contained a certain Category, then it's certainly feasible that the Visual Editor could use that information to limit the list of pages it shows in the selector. (That's probably two separate feature requests instead of just one, though.)

Reply to "options to select from wikidata-item-name? wiki-page-in-category-name? non-local-wiki-page-name?"