Can the opening table in the “Names” article be improved?

At the beginning of the Names article, there is a large table. In my opinion, it could be improved—not in terms of content, but in terms of style. The content and structure are probably a topic for a separate discussion, where we should consider the broader context of all pages about names.

I suggest improving the template Template:Map Features:name in the following way:

  • remove the Value and Element columns
  • improve the text formatting

The Value column is unnecessary. It is already clear that the values of the name key will be different. This column exists, most likely, because no one has really thought about whether it is needed in this table.

The Element column also adds very little. It mainly shows that tags like name:left, name:right, bridge:name, and tunnel:name are used for ways. This detail can be explained in the Comment column instead, in the cells that describe these keys.

All key=* and key=value pairs should be formatted as code. This is not only about visual style, it also helps reduce cognitive load when reading the text.

So, are these changes needed for the template? If yes, I can start with improving the style. As for removing the columns, a more experienced contributor should confirm whether this could break localized versions of the template.

Below you can see examples of how it looks now and how it could look after the changes:

And this is an example of how two largely redundant columns obscure the truly key content on the right on mobile devices. (By the way, Template:Feature is also a problem here.)

Responsiveness issues

I don’t know anything about the mechanics of wiki templates in general, so I will leave that to others and only comment on the formatting. It seems less clear now which items in the left column are links (they are all links in this extract, but not in general).

I think the order in :[__] is wrong as the colon is optional so should be inside the parentheses.

I’m not sure about replacing xx with __ - I’d need to see the row where this is introduced.

Is there a significance to the use of italics for parts of the keys?

In general, there may be a trade-off between changes that work in this table versus user expectations based on similar tables on other pages. For that reason I’m not sure about moving the node/way/relation icons out of their own column.

1 Like

removing links or link visibility is a bad idea

3 Likes

Color really matters; I overlooked it, thanks. Using slightly different link syntax, it will come back, but together with = and the asterisk *.

I used italics because I thought it would highlight suffixes and prefixes… Probably not such a good idea, since it’s really quite subtle.

Regarding the underscores: right now, the fact that [xx] is a placeholder isn’t explicitly stated. We could add text like:

Replace [__] with the language code, such as en for English, zh for Chinese, hi for Hindi, etc.

And how would you feel about using the symbols [✕✕]? They stand out more from letters and thus make it clearer that this is a placeholder:

ezgif-41a10b826726f1b3

I would remove that [xx] completely. It makes the table much harder to read than necessary. There is no added value in having that for every tag in the table

Have a table with only the major keys, then a part that says “and here’s how you add any of these tags for different languages:”

And as Mateusz wrote, don’t remove the links that lead to further descriptions of the individual tags.

1 Like

I partially agree with this. This placeholder is clearly unnecessary, for example, for int_name.

It can be left only in the field where multilingual support is mentioned.

I didn’t remove the links; it’s just that formatting the text using <code></code> seems to override the link color styles.

1 Like

I made the changes. The tags are now written using the standard template {{Tag|name}} and are formatted consistently with the rest of the article. The =* notation serves to inform users that the values of these keys are not uniform. This is more elegant than having a separate “Value” column. Removing that column did not break translations into other languages.

Additionally, the equals sign and the asterisk can also be omitted if the {{TagKey|name}} template is used.

Here is how it was before:

Result after the changes: