Item talk:Q712

Should this key have defaults for onNode, etc?

The wiki templates are currently set up such that, if a Tag page does not specify values for onNode, etc, it will display a question mark icon -- but only if the entity page for the key does not have the corresponding property defined. Otherwise, it will display whatever the key entity page says -- either yes or no, but never the question mark icon.

In the case of this key, source, it, appropriately, had all the properties set to yes. This meant that it was impossible for a specific Tag page to display the question mark icon -- it would either display no (if that was explicitly set), or yes otherwise. On a few particular Tag pages, editors felt that this was incorrect, and wanted to display the question mark icon -- and they found a kludge that caused this to happen (specifically, due to a bug in how the templates were set up, if an invalid value (but not blank) was given on the Tag page, that would preempt the use of the default from the key).

I attempted to address this, at first by arguing that the fallback was appropriate, and failing that, that removing the default (thereby allowing the question mark icon to show on particular pages. Both options have now been rejected, so I'm bringing this up here to get more discussion on how we want to move forward. JesseFW (talk) 22:52, 20 June 2023 (UTC)

Each key (on Key:* page and data item) should be given onNode, onWay etc.
Not setting onNode, onWay etc. values on specific tag pages causes the page to appear in Category:Pages loading applicabilities from data item, which is a maintenance category and should ultimately be empty.
Entering "?" instead of "yes" or "no" is temporary and lets editors know that this data should be filled in.
The values for onNode, onWay etc. should be set manually because "Key:* and "Tag:*" pages are official documentation, not data items.
Leaving the onNode, onWay etc. fields empty results in fetching the data from data items that doesn't have to be true because it wasn't set by users at all. This further results in the fact that most users will have no idea where the values came from. maro21 21:17, 21 June 2023 (UTC)

Not that I would be in favor of this solution, but if we decided on the variant of omitting the onNode/Way/etc. information for certain keys, these must of course not only be gone on the wiki page but also in the data item. --Chris2map (talk) 21:32, 21 June 2023 (UTC)

Which solution? maro21 21:38, 21 June 2023 (UTC)

Yeah, solution wasn't the right term. Just wanted to note that data item and wiki page would both be adjusted (if). --Chris2map (talk) 23:01, 21 June 2023 (UTC)

There are a number of different issues here. With regards to the "fallback function of the Module:DescriptionFromDataItem" (thanks Chris for that useful name for it), I'd enthusiastically support turning it off -- I think it's very confusing, and not very useful. Once it was turned off, the presence or absence of the onNode, etc. properties on the Key entity page wouldn't matter for what shows up on the Value page. The other (or maybe another) issue is whether there's a useful distinction between setting the template parameter to blank vs setting it to "?". I don't think there should be a distinction between those -- in my view, they should mean: "not yet specified" in exactly the same way. We may have to undo some further data item stuff to get there, but I think that's the right goal to aim for. If/when we get there, I'd (mildly) prefer blank vs "?" to express "not yet specified", mostly just because it's already implemented -- but I'd be fine with pushing Joto to accept "?" as a synonym if desired. I hope this makes sense? JesseFW (talk) 21:54, 21 June 2023 (UTC)

setting the template parameter to blank vs setting it to "?". I don't think there should be a distinction between those -- in my view, they should mean: "not yet specified" in exactly the same way - I agree, but I set them to "?" because of the fallback function. I also prefer to leave them blank if not specified.

I'm not sure if the fallback function is useful or not. For sure it helps to add rendering to every building tag (if we turn it off, they will have to be added manually), but I don't remember other examples where it can be helpful. maro21 18:25, 23 June 2023 (UTC)

I agree with you. By the way, the naming of "fallback function of the Module:DescriptionFromDataItem" is taken from Yurik's module code. He has already used this term in his programming. Stopping fallback to key's data for onNode... is probably very easy to achieve. I'll test it in the sandbox. --Chris2map (talk) 17:16, 22 June 2023 (UTC)

Seems to work! Compare: