Item talk:Q23789

Q23789 replaced Q23788

Zimtschnecke we changed the name from ref:stockholmarchipelagotrail.com to ref:stockholmarchipelagotrail

i.e. Q23789 will replace Q23788

do I need to do anything more...

- Salgo60 (talk) 03:50, 9 June 2026 (UTC)

I finished wiping the old item. We discussed this recently, and items that existed only for a short time can just be recycled. This item was just missing the sitelink, but otherwise I think all good :) -- Zimtschnecke (talk) 04:16, 9 June 2026 (UTC)

only the mul label should be set

FYI Zimtschnecke (talk) 05:42, 9 June 2026 (UTC)

Zimtschnecke I agree in a perfect world... is that agreed in the OSM community?!?!? Lesson learned from Wikidata is that people normally SPARQL query using local lang and fallback en i.e. "old queries" before mul will fail if you dont set en? - Salgo60 (talk) 09:30, 3 July 2026 (UTC)

yes! all non-mul labels got wipped for keys and tags. for other meta-items, multi lang labels are fine. https://wiki.openstreetmap.org/wiki/Talk:Data_items#Multilingual_default_labels_on_data_items Zimtschnecke (talk) 09:56, 3 July 2026 (UTC)

one should also never query the labels. one should always query the property with the tag/key ID. Zimtschnecke (talk) 09:57, 3 July 2026 (UTC)

Zimtschnecke Yes, but I'm talking about how users retrieve labels in their preferred language.

Most queries use the label service like this:

SERVICE wikibase:label {
  bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en".
}

If the default labels only exist in mul, existing queries would no longer return labels unless they are changed to:

SERVICE wikibase:label {
  bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en".
}

So changing the default language from en to mul isn't transparent—it requires many existing queries to be updated. Salgo60 (talk) 10:05, 3 July 2026 (UTC)

You can bring this up in the other discussion if you want. This was a data admin decision. However, there is no working SPARQL endpoint for the OSM data items anyway right now... -- Zimtschnecke (talk) 10:25, 3 July 2026 (UTC)

Fair enough. If no one is querying the data yet, it's a non-issue. I was just thinking ahead to when a SPARQL endpoint exists and existing query patterns start being reused ;-) - Salgo60 (talk) 17:11, 3 July 2026 (UTC)

Additionally, translations are not provided for keys and tags. Consequently, querying local labels (in a different language) would generally not make sense at present — with the mentioned exception of meta-items such as groups, etc. — It is a good idea to reference the permanent ID in the case of a key or tag query. --Chris2map (talk) 17:24, 3 July 2026 (UTC)

Sorry long answer but I think this is important and I understand this thread is not the right place for a change but.... still very important... I think this is an example of technical debt that in the long run is a problem for OSM to get better globally accepted (its another discussion but... ;-) )

If OSM wants to evolve into a truly language-agnostic platform, introducing more languages directly into keys and tags feels like a step in the wrong direction. It will inevitably lead to situations where, for example, I as a Swedish mapper cannot understand keys written in Chinese characters, and the opposite will be true for others.

We previously had a (now banned) user who started adding country codes directly into tag names instead of solving the problem at the data model level. See the forum discussion:

• forum "Proposal to convert keys lst:diarienr, lst:nvrid to ref:SE:diarienr and ref:SE:nvrid"

I encourage people to look at Wikidata / Structured data on commons solve this problem. They separate language-independent identifiers from multilingual labels, descriptions, and media, allowing properties, items, and images to work seamlessly in more than 300 languages. That approach scales much better than embedding language or country-specific semantics into tag names.

• Stable identifiers should be independent of language

if we look at Wikidata properties are P18 and P625... then use labels to make it human readable and also easy to change names

Localizing identifiers creates multiple spellings for the same concept, increasing documentation, tooling, validation, and long-term maintenance costs. Keeping identifiers language-neutral while translating human-readable labels separates machine semantics from presentation.

• examples how languages are supported P18 / P18 uselang=zh fallback english / P18 uselang=fr / P18 uselang=de / P18 uselang=ar / P18 uselang=sv

• OSM already shares many of the same internationalization goals and Unicode support. Adopting the same architectural principle—stable, language-independent identifiers with localized human-facing labels—would provide a more scalable solution than embedding language- or country-specific semantics directly into tag names.

The separation of identifiers from localized presentation has already proven to scale in projects such as Wikidata and Structured Data on Commons. OSM could benefit from applying the same architectural principle.

- Salgo60 (talk) 09:45, 5 July 2026 (UTC)

In the id editor get ref:stockholmarchipelagotrail clickable

Zimtschnecke looks like ref:stockholmarchipelagotrail is not clickable in the ID editor what is missing?

• example node/13956211801
• my issue [https://github.com/salgo60/Stockholm_Archipelago_Trail/issues/424 #424)

- Salgo60 (talk) 13:23, 22 June 2026 (UTC)

iD does not (currently?) support formatting URLs from data items directly I think. Formatting needs to be defined in https://github.com/openstreetmap/id-tagging-schema. CC @Mateusz Konieczny, maybe you can comment on this?

Yes, keys/tags need to be defined in https://github.com/openstreetmap/id-tagging-schema to be supported as an iD preset or its value. I am not familiar with https://github.com/JOSM/tag2link so I cannot comment whether either adding its presets to iD tagging schema or iD somehow supporting it directly would make sense Mateusz Konieczny (talk) 16:10, 22 June 2026 (UTC)

It is being imported into https://github.com/JOSM/tag2link, so any projects using this as a base will have it working. -- Zimtschnecke (talk) 13:31, 22 June 2026 (UTC)

Thanks now it works that the value is clickable but not the tag itself example node/12769968654

• my issue #424
• my question on OSM forum "Get ref tag clickable "

I can see we have the same issue with

• Q23184 ref:NVRID

Salgo60 (talk) 09:59, 3 July 2026 (UTC)

Very interesting. I did not know, that tag2link gets then used on the OSM webpage. Cool!

Not sure why ref:NVRID is not working. It has been in tag2link for a while already? Zimtschnecke (talk) 10:02, 3 July 2026 (UTC)

my guess

• P8 it lacks a formatter string on Q23184
• P12 it lacks Wikidata concept on Q23184
• maybe set in Wikidata P13786 OpenStreetMap key see WD P14545#P13786

- Salgo60 (talk) 10:12, 3 July 2026 (UTC)

I don't think they effect anything. It is in there, see https://github.com/JOSM/tag2link/blob/3c4e2d14981914265f9f93ea1500fee296d5ffef/index.json#L2968

Looks the same as for ref:stockholmarchipelagotrail Zimtschnecke (talk) 10:28, 3 July 2026 (UTC)

Zimtschnecke ref:badkartan.se Item:Q23784 now started to be clickable see example node/345387279 - Salgo60 (talk) 11:03, 3 July 2026 (UTC)