As you may have seen by now, OSM Americana now labels indigenous territories, including Native American tribal reservation boundaries in the U.S. This is more or less the first vector style and the first internationalized style to depict the reservations, so I think it could have a significant impact on how the community thinks about modeling them in the database.
From the department of redundancy department
We made a last-minute decision to include both the name of the reservation in the user’s preferred language and the name the reservation primarily goes by, if it differs. For example, several pueblos in the Santa Fe area go by a native name in OSM (including the Zia Pueblo, who generously allowed us to use their sacred symbol on the map):
This is similar to how we label cities, based on longstanding convention from print cartography, but we’ve extended the practice to the reservations. Many tribal governments have designated their native languages as official languages. Although the map style doesn’t normally gloss native names of administrative boundaries, language preservation is so often a key priority of tribal governments that the native language seems especially relevant.
The bilingual names may look unwieldy in a standard map style like OSM Carto, but it’s even worse in an internationalized style like OSM Americana, which can only assume that the entirety of name=* is a native name:
Simple solutions
Ideally, the map would deduplicate in name:en=* with any English name that appears in name=*. To do that, it needs to look for a predictable delimiter. Despite the title of this topic, slashes are only one of the ad hoc delimiters that appear in reservation names. When @NFZANMNIM added a large number of native names in 2022, they single-handedly established a convention that would later be adopted by the Canadians: a slash only between two Latin names, or a space otherwise.
Unfortunately, both slashes and spaces appear abundantly in even monolingual names, so they make for unreliable delimiters between names. Even if a renderer has the technical capability to perform Unicode-aware regular expression matching – Americana does not – it would still be very error-prone. For example, many indigenous American languages are written using Americanist orthographies, which can mix Latin and Greek letters with symbols that are shared among multiple writing systems. Automatically isolating “Latin” text under these conditions requires making a lot of assumptions.
Some mappers and programmers will look at this situation and quickly think up a simple solution: tag the languages, then construct the names from those languages. Indeed, plenty of boundaries have default_language=* tags. But a reservation has a nuanced relationship to everything inside. We cannot assume a town on a reservation is named in the same languages as the overall reservation, and that’s before getting into the fascinating topic of what exactly an Oklahoma reservation has jurisdiction over.
Yes, the semicolon
Instead, over the years, many U.S.-based mappers have expressed a clear preference for the semicolon as the name delimiter, both in discussions like these and by their actions in the database. Mappers want to stop fussing over punctuation and let data consumers split name tags like any other tag. The semicolon is not new, but software support for it was lacking for so long that mappers in more forwardly multilingual parts of the world adopted ad hoc delimiters as a more practical solution for their needs. Unfortunately, those arbitrary practices have become entrenched, to the point of overseas mappers sometimes overriding our local judgment with their own familiar delimiters.
We have an opportunity to forge a different path. The newly rendered reservations make it easy to visualize the what-if scenario of ad hoc delimiters versus semicolons. The horror story of a raw semicolon appearing on OSM Carto is now only one possible scenario. Optimizing away this outcome, at the expense of more sophisticated uses of name tags, becomes a textbook definition of tagging for the renderer.
At this point, the relations for about 100 reservations use a slash to delimit two names and many others use a space for the same purpose. If the U.S. community reaches a consensus to establish the semicolon as our preferred name delimiter, then we can retag these features without much fuss. We would also need to document the choice and ensure that validators respect it. Can we finally get there this time?