Slash-separated Native American names

Thanks, bidirectional text is a great argument for a formal delimiter. Computers have a lot of difficulty deciding whether mixed-direction text should be reversed or not, and a language-neutral punctuation character doesn’t help at all. In Unicode plain text, displaying bidirectional text in the correct order sometimes requires the use of invisible control characters. I think most mappers would prefer to use a semicolon that would be parsed out more literally.

Osmose has been flagging the slash-delimited name anyways. I asked the developers to exempt any double-barreled name that’s a concatenation of multiple other name tags:

Good discussion - thank you!

Generally I’ve seen the slash as a political compromise when a place really does have two equally used names. As alluded upthread, “Londonderry / Derry” is the obvious one, but there’s also “Bruxelles - Brussel” (with a dash rather than a slash… sigh).

In the UK, and Wales in particular, we follow the general principle (which I think is sensible) that the name= tag reflects the dominant language spoken locally. So it’s Swansea rather than Abertawe, but Y Bala rather than Bala. There are a few rare examples where the slash is used because there isn’t one dominant language (Aberteifi / Cardigan, and Ynys Môn / Isle of Anglesey).

But I’m aware that this isn’t a universal practice, and we did have one rather awkward episode a few years back where a mapper from another country came to study in Wales, and assumed that the “slashes at every opportunity” approach from his home country would also apply there.

It seems logical to me that applying the Wales principle in the Oneida case would result in removing " / kanaˀalóhaleˀ" from the name tag, given @Minh_Nguyen 's stat of a 1% population. But I’ll leave it to you locals to have that fight :wink:

In the meantime I’ll do a little bit of work on my Lua rendering profile for North America to filter out this sort of thing.

To try and keep this topic focused on Native American place names in the US I’ve split off some posts to a new topic in General talk. Lets continue any further globally focused discussion there.

1 Like

I’ve also seen the ‘/’ practice being done in New York State on Seneca reservation. Take the city of Salamanca as an example (which is within the reservation). I’m in support of it because it is a bilingual area with active Seneca language restoration and awareness. Many signs erected by the state are bilingual in the area.

The only reason for any type of separator character is to be able join two or more names. If the tribe has one official name for thier land then there should no need for a separator.

After a bit of warmth / heat (and thankfully, eventually light) at some talk-ca posts about someone rather aggressively (and insensitively) re-naming some boundary=aboriginal_lands (multi)polygons in Canada, the (USA Native American Indian) section of United States admin level - OpenStreetMap Wiki has expanded a bit to state that these are emerging along a “case-by-case” basis. There are a number of sensitivities and possibilities here, and so the reality is that “many options are possible” on these entities. You might have place=* nodes with a value of village, you might not. You might have a boundary=aboriginal_lands tag along with an admin_level=* tag (not the-usually-associated-with-this-tag of boundary=administrative). You might have tagging in “the local language” (as an adjunct tagging convention, or even the only method by which things are named). You might find that some of these have further subdivisions “inside of” the boundary=aboriginal_lands polygon.

What that wiki says (in essence) is to, largely speaking, “leave it up to the people upon the land” to describe this / these attributes, and use their conventions as OSM’s best practices for their land (and people). The net result is that parsing these data / figuring out what to do with them for any given use case is going to be rather open-ended in its necessity to cope with a wide variety of data here. Such “parsing difficulties on the back end of our data” come as part of the (higher) cost of “case by case.”

As far as I can tell, most of these names were not introduced with the level of care that you’re recommending, but rather indiscriminately and unilaterally by one mapper, not only in the U.S. but all across the Western hemisphere.

While I appreciate the need for indigenous languages’ representation in the database, Oneida’s slash-delimited name seems to be a case of overzealousness. It isn’t located inside a reservation, though the Oneida Nation does run a casino outside town. Judging from their changeset comments, their general approach is apparently to systematically copy names out of online dictionaries. But these dictionaries only say what the name of the place is in a given language, not that it’s one of the main languages there.

As for the choice of delimiter, it seems to be a personal whim rather than a matter of principle. So far no one has claimed that the tribal authorities have a strong preference for the slash over other punctuation that a data consumer would apply if the standard semicolon were tagged (which might well be a slash anyways). A “case by case” approach sounds like a tradeoff in favor of something theoretical at the expense of something real.

2 Likes

I reflect the consensus from the talk-ca thread. “Case by case” seems to be the realpolitik of the situation. This literally means “practical rather than moral or ideological considerations,” but actually practicality AND ideological considerations are important to consider, given the truly sensitive nature and histories of the subject.

My “introduction” towards these names (and conventions) is forward-looking in light of the talk-ca discussion, and only partly based upon the data I saw was already (and do see now) in our map (data). Although, I have been looking at these data for many years and was (I hope) somewhat helpful at the transition away from protect_class (numerical values) and towards the (more harmonious, at least starting after its Approval in 2019) of boundary=aboriginal_lands.

I realize “slash-separated” is the subject here, but I decided to zoom out to a broader sense of how truly wide these data can go, as I believe the project as a whole, worldwide, benefits from this wider perspective on the topic.

A “so far recap:” (yes, I’ve skipped some, hopefully minor things, feel free to re-inflate them)

It’s a lone mapper thing and de facto accepted practice, at least from a USA/Canada/North American (México, too? unclear) perspective (I think that’s “about” what Zeke meant). I’ll toss in that adding México and/or saying “North America” couldn’t hurt (add Spanish and some other languages, which is already done with French and some other languages with Canada). There is a trend towards “all of North America” when two of USA, Canada and México are discussed about “how we do things ‘around here’”).

These (native names using / slash characters) are added by non-locals, largely one, who doesn’t seem to get a lot of input "from the people of the land,"now widely noticed, thanks to Minh for pulling tight focus on this. “Engaging local tribal communities in mapping their own lands” is an expressed ideal. The “sense of stewardship” in our map “as ours to present, with honor” now lies before us. We’ll want to tag our best to map our best.

name:lang tags seem a solid, established method, though sometimes getting which dialect is correct can challenge. I’ll toss in this might be where a scholar (see the recent talk-ca thread [Talk-ca] First Nations reserve naming) or those with “already some overlap” here (these topics, these sorts of conversations) could step in and help people chat together…which ISO codes of this or that dialect are correct, reducing cultural friction perhaps, kind of stuff. Someone listening on the OSM side to structure that into a “start here” approach can work. Really, the more who listen, the more the ball can roll towards good motion. It may be three or four people who can nod heads together, it may be a whole band of people take a vote in a meeting, “we’ll see.”

Sometimes, alt_name is used, downstream users of our data should know that. We might want to say that descriptively and take pause to invent something prescriptive, or not, and remain in “observe and learn” mode. There are a lot of possible directions we could and already are going in and this really is a highly fluid kind of design, exceedingly difficult if not impossible to predict well. We really must be (at least partly) very much in listening mode.

Semicolons can work when “a name tag does have more than one name in it” and slash character / is a tagging error. “Semicolons seem here to stay.” The characters solidus / space hyphen - and octothorpe # have been called out as “do not use these in names” (they are old separators we want to replace). Many downstream data users “cope with” semicolons reasonably predictably well. Establishing (as a line of “the paint has dried hard”) that semicolon is a separator as we are describing here causes some downstream ripple in things like JOSM and Osmose. Unicode / mixed directional text and other difficulties (perhaps invisible or quoted characters are necessary in some cases / contexts) complicates this.

In some cases (e.g. rendering text for map tiles) some of this can be done with tweaks to Lua profiles. The slash character / is used in political and cultural distinctions on multiple continents and for multiple reasons.

A “best initial seed case” scenario might be a name:xy=* tag in the local preferred language, plus a name=* tag in “English” (that might be Canadian English, US English, Australian English…) as is OSM’s convention to tag a name=* in English, if possible and appropriate. Other (any?) languages are welcome to be added. Slash characters are to be avoided (along with hyphen, spaces and octothorpe) going forward. Let’s think about how we might communicate intended changes (like deprecating slashes) to downstream users and bump it around.

It seems like there is some fairly wide understanding about this (hundreds of views of this topic). Can someone else take the baton away from me about now and keep running this towards a finish line? It may actually turn into something like a mechanical edit (to filter out slash characters…) as an earlier step. Maybe a middle step.

Stepping away…

My apologies if this has been discussed previously, but what is the thinking on appending First Nations (? - again, my apologies if this is the wrong term?) names to English names e.g. Changeset: 146720271 | OpenStreetMap and Changeset: 146720271 | OpenStreetMap.

Should they be tagged on as a “/ name” or separately tagged as name:xxx= ?

This was discussed a while ago, but without a conclusive resolution.

1 Like

OSM is a database first. This means that entering messy data leads to messy UIs. Putting a slash in the nsme creates data. Multilingual signs or label should formated at the UI level. This allows the data and its representation to be keep seperated. I all case you should start by setting the individual names by the appropriate language.

Keeping them this way will make your example much easier. Allowing the use of a simple text formatting library to control how the final text is displayed. A new tag “formated_name” could be created to contain this special formatting string.

So for places with roots in a First Nation language, the formated_name tag would contain [name:browser_locale] / [name:(replace with root language)]. This would show the name of the prefered language of the user followed by the root name. The mapper could easily switch the name order along with changing the type or number of separator characters. As long it is something supported by the formatting library.

This week also fix the complaint from Europeans about handing crossborder signs. In case of place name, the browser language would appear first with the local versions following. Those using a local one would see theirs in front. For directional signs such as city limits, all sign nodes would contain the same set of city names. Though each would display the translations in the order consistent with the local language and culture via a localized formatting string.

1 Like

Can a moderator please move the digression about multilingual names over to Slash-separated Native American names or a new topic? The current topic is actually about place classification, not place names.

Done, thanks!

2 Likes

Sorry to run things off the rails! :cry:

Edit: This post was moved from New England thread

Multiple values are seperated by ; in OSM, not slashes. I’d be more inclined to newline against that and fix the seperators in the multivalues

1 Like

Have I got the thread for you! :grimacing:

As you can tell from that thread, I would very much like to see a resolution to these fly-by-night slashes before they become part of local OSM lore and convention.

2 Likes

I think it should be language-coded, but I don’t think ISO-639 has a code for some Native American placenames

1 Like

For the couple of places I’ve seen/tagged Native American names I was able to find the two or three letter ISO code for those languages.

That said, in one instance the sign on one mountain simply gave a single name but when I looked up the language code I found that there were several dialects in that language with different codes. I ended up picking one but could well be wrong on my decision.

Anyway, there are codes for at least some of the Native American languages. I suspect all of the major language families have a code but am not sure about all dialects.

1 Like

Yes, we’re still going to need to solve this for languages that don’t have an ISO code, since we’re talking around a hundred dialects. More than a few are bound to not have a code.

1 Like

The spelling could be specific to one of the dialects or common among all of them. While mapping in California, I’ve encountered situations where it’s difficult to tell. Sometimes a name comes from a tribal authority that represents a merger of multiple historic tribes that share a common tradition.

If you need to tag a name that doesn’t have a well-fitting ISO 639 code, there are a couple possibilities:

  • Find the code for the language family and append -x- and a short identifier that unambiguously identifies the language.
  • Instead of a human-readable identifier, append -x- and a Wikidata QID representing the language, so that data consumers can key off it regardless of the spelling of the language’s name.
  • Add it in alt_name with a note.

Note that, in some cases, the IANA has assigned a BCP 47–compliant subtag for a language that lacks an ISO 639 code. For example, Ohio has its Mingo name as i-mingo, though some systems now prefer see-x-i-mingo.

In any event, the mappers (really, mapper, singular) who go around adding the slash-separated names have usually added or preserved the name:* tags. The issue is more that, to the extent these names also belong in name, as one of the primary locally-spoken names, the / delimiter could easily be mistaken for a part of a monolingual name; there’s not a lot data consumers can do with it.

2 Likes