Underscore/colon as language field separator

[SvanteRichter]

Hello!

Could I ask the reason to use underscore in the language fields (name_en and name_de)? Seems like protomaps are using colon, and openmaptiles have moved to colon but are keeping name_en, name_de and name_int (probably for compatability? openmaptiles/openmaptiles#279).

When adding more languages (like for #68) is the plan to align with protomaps & openmaptiles and use colon or will underscore be used for those?

I'm asking since examples like maplibre (https://maplibre.org/maplibre-gl-js/docs/examples/language-switch/) and plugins (https://github.com/teritorio/openmaptiles-gl-language) seem to default to using colon as the separator.

It also seems like some docs here use colon: https://github.com/shortbread-tiles/shortbread-docs/blob/main/shortbread-website/static/taginfo.json#L18 and some issues use it too (#22) so I think having a clear, documented separator might be nice.

Thanks!

[joto]

For maximum compatibility with lots of software it is better not to use "strange characters" like colons. Even if it seems to work, sooner or later you'll run into problems somewhere. In this case for instance it would mean we have to escape those names in the PostgreSQL database properly if you are using a tool chain that uses the database. Not a huge problem, but annoying enough. Or you process the data in some programming language and then you can't use that name as the name of a variable. Life is just easier if you don't use these kinds of characters.

[SvanteRichter]

If there was no prior art I might agree with you, but the other two major opensource tile-schemas use colon, OSM uses it for the same attributes, and shortbread already uses colon for other attributes (tower:type, recycling:glass_bottles, recycling:paper, recycling:clothes and recycling:scrap_metal). I'd lean more towards going with colon.

Seems like OSM uses underscores in place of spaces and colon to reference subkeys like short_name:de or railway:track_ref and also seems like underscores are used as a space replacement in shortbread in other places like state_capital or isolated_dwelling, so using underscore as a localization separator might not be the best. It seems like in almost all cases underscore is used as a space replacement and colon is used for subkeys, except for the two language fields currently in the spec.

Either way I think having some clarification would be good.

[pnorman]

This change would only make sense if we skipped 1.1 and went right to 2.0. We can't change name_en to name:en in a minor revision.

[SvanteRichter]

@pnorman Adding new names to the spec and deprecating the old ones (like openmaptiles did) would not require a major version bump, right?

Either way, I think it would be good with some clarification on what the plan is going forward for separators and the semantics of colon/underscore.

[pnorman]

@pnorman Adding new names to the spec and deprecating the old ones (like openmaptiles did) would not require a major version bump, right?

Having both name:en and name_en would not require a major version bump. It would increase the amount of data we are sending