[RFC] Feature Proposal - Add languages: tags for name rendering

[Minh_Nguyen (Minh Nguyễn)]

There’s a lot to unpack here…

@aseigo

Also, I hate to ask again, but: do you have an example of a country which has multiple languages which are considered of equal standing and which also has no prescribed ordering of the languages for the purposes of maps, signs, etc.?

Languages of the United States

@aseigo

This would be worse in practice as it would result in renderers not applying the officially mandated ordering. Most places that have multilingual naming and signage which follows it have official guidelines for ordering.

If you’re referring to the languages:official=* part of your proposal, this is a simplistic concept that may work in some regions but not others. Many jurisdictions confer special status upon certain languages while avoiding the term official language. A language may be official in practice but not in theory, or in theory but not in practice. Some jurisdictions declare official languages for certain people or purposes but not for others.

For example, in my home state of California, the constitution declares English to be the official language and therefore prohibits people from spelling their names with diacritical marks, yet government agencies sometimes try too hard to communicate with me in Vietnamese, one of the many languages they’re federally mandated to provide for certain services. There are whole neighborhoods where you will find hardly any signs in the Latin writing system. That said, road signs are almost universally in “English” – which includes a plethora of Spanish-derived names, replete with diacritics.

Massachusetts declares English to be the “common public language”, but government materials are routinely provided in a variety of commonly spoken languages. Louisiana recognizes a constitutional right for “the people” to promote heritage languages, originally an implicit way to protect the French-speaking majority, but over time, this provision has been interpreted at times to protect a wide variety of minority languages too.

South Dakota declares English and Sioux to be co-official statewide, but good luck finding any wayfinding signs in Sioux outside Sioux reservations. Conversely, the tiny town of Oldenberg, Indiana, proudly signposts its streets in German, even though the town council lacks the authority to declare an official language. The state’s official language is English, but they’ve even managed to apply a German name to the state road running through town.

@aseigo

@SimonPoole

doesn’t cater for situations in which the relevant tag values differ on non-admin boundaries

Do you have examples of this in the real world, specifically for languages? Language policies are generally set by governmental agencies, and typically map to boundaries within their jurisdiction.

Your proposal isn’t just about language policy; it also calls for a languages:preferred=* key and seems to place more importance on it from a software perspective. Many places don’t regulate the languages that residents are allowed to use, let alone which languages software systems should associate with the place.

The proposal downplays the possibility that language usage can be fluid and nuanced:

This sometimes happens in the case of monuments, streets with historical names still in modern use despite language changes, or specific geographic features. This is uncommon, however, and nearly all features which are not administrative boundaries should not have languages:* tags.

I just wonder what’s your basis for making such sweeping claims about the world? Have you ever been to a Chinatown, or any ethnic enclave for that matter? At least in North America, even when an ethnic enclave has a well-defined boundary, language usage inside and outside is far from uniform. Going back to Oldenberg, the roads and shops may be named in German, but the buildings, the churches, and the maypole are named in English.

But really, what does this have to do with “preference” anyways? If the language of a thing is in a certain language, then say so. If the user prefers a particular language and there is a name in that language and the software is capable of presenting it, then the user’s preference is none of the mapper’s business.

@aseigo

(Whether name should contain multiple languages or not would be up to editors interested in that area, as it is now … but it’s kind of a moot point as no matter what is put there, it has unresolvable drawbacks such as poor audio rendering, or how hard it is to make it globally consistent. Due to name being, at least imho, broken for multi-lingual cases, the proposal focuses instead on new tags which may actually resolve the problems seen with using a single name.)

Please name the “audio renderer” that you’ve been referring to in multiple threads, or at least describe it in more detail, so we can understand the limitations and constraints that have led you to your proposed solution.

@aseigo

Of course, if someone can point us to city street signage that does not display names in some order, or even one where that order rotates from street to street in deference to fairness, that would be very interesting and represent a difficult use case to model.

A few weeks ago, I was wandering around Seattle’s International District looking for some Seattle-style teriyaki and bánh mì. At each intersection, the street signs at the northwest corner are in English followed by Japanese, while on the southeast corner, the signs for the very same streets are in English followed by Chinese. Further down Jackson, the signs are in Vietnamese instead. Meanwhile, the shop signs are a rowdy mix of all four languages.

Of course, there are other problems with assuming that signs are laid out linearly in plain text. This sign is laid out in French, English, and Spanish, but English clearly has priority, because it’s bigger:

File:Downtown New Iberia Trilingual French, English, Spanish signage.jpg

But just because a name is bigger doesn’t mean it’s the main name. One time I noticed that a Vietnamese restaurant in Brunei posts its Malay name in Jawi first and much larger than the Malay name written in Latin or the English name, but it turns out the Jawi name is decorative or pro forma; no one uses it.

And there’s more… lots more!

@Minh_Nguyen

When the City of Houston turned streets such as Turtlewood Drive and Bellaire Boulevard into “Turtlewood Drive Ngụy Văn Thà” and “Đại Lộ Sàigòn Bellaire Boulevard”, respectively, they just stuck the Vietnamese-language signs wherever there was enough room for an additional sign:

Some of the English signs are so faded that an English-speaking traveler may need to rely on the Vietnamese signs in some cases. A map could show them something like “Turtlewood Dr. / Ngụy Văn Thà” or “Turtlewood Drive — Ngụy Văn Thà” or “Turtlewood Dr. (Ngụy Văn Thà)” or “Turtlewood Dr.” above the street and “Ngụy Văn Thà” below it. The specific delimiter here only matters to the map style designer. The order of the names in name doesn’t matter much either, because the preferred-language name will come first in any savvy map style or navigation guidance instruction.

The city only dual-named the through streets in this neighborhood, but other things are named differently. Turn 90 degrees clockwise and you’ll see a restaurant whose name is signposted in interleaved English, Chinese, and Vietnamese above some shops that are in English only or Vietnamese only:

The San Francisco Bay Area, where I live, happens to be very linguistically diverse. Many places of worship around me offer services in multiple languages and make every effort to unify their congregations despite a language barrier. This Jehovah’s Witness Kingdom Hall serves both English and Spanish speakers on equal terms. The placement of English to the left of Spanish is purely coincidental. As far as I know, they don’t have a preferred delimiter either.

This supermarket has two signs visible from the street. The logo on the sign in the foreground puts Korean on top of English, while the sign on the façade puts English to the left of Korean:

This doctor’s office posts its English name above and to the left of its Vietnamese name, but I think he mostly serves Vietnamese-speaking patients:

And let’s not forget that sometimes a feature can have multiple names regardless of language. Before it moved earlier this year, this flag and costume store was either “Funhouse/Flaghouse” or “Flaghouse/Funhouse”, depending on whether you looked at the sign on the front or the rear. (Customers typically parked in front and entered around back.) If I recall correctly, the receipt had both names printed on it, separated by the delimiter “***”.

I would be remiss if I didn’t close this comment on a more positive note. There is certainly room for improvement in how OSM encodes feature names. But if the megathreads around name=* are any guide, consistency is almost a nongoal because it hardly exists in the real world. What we should be aiming for instead is to accurately describe each feature as people experience it, minimizing our own personal preferences as mappers to a reasonable degree, and structuring it just well enough for data consumers to adapt to user preferences. If data consumers sometimes have to rely on heuristics and generalizations, at least that’s better than mappers having to make those generalizations on their behalf. After all, there’s only one database but many data consumers.