Forking the discussion from Acknowledging provinces in website search results, where some interesting points about localization are raised:
Most of the words in OSM tags are English (en_GB specifically) and I wouldnāt say they just happen to be by chance. It is intentional. That said, the full set of words in our tagging schema does not match any particular regional dialect of English, and it even includes some words borrowed from other languages. Further, the point is well taken that the meaning of some OSM tags have deviated from that of the original British English words. I call the resulting dialect OpenStreetMap English (en_OSM). The portmanteau āOpenstreetmaplishā is fun, but it would seem to suggest an entirely separate language from English. I donāt think we have deviated that far yet!
I have reservations pushing again more towards one or more of the national English dialects. For one thing, as you correctly state, it has real political implications and the push towards American/Canadian/British/Australian terminology leaves us vulnerable to serious edit warring. For another, it poses problems in understanding for those who only speak and understand Openstreetmaplish.
I have mixed feelings about this. Those of us with many years of engagement with the project know OpenStreetMap English well and it can bolster cross cultural communication as a lingua franca of sorts. However, for less engaged mappers from English speaking regions it can easily be a source of confusion and conflict because they do not realize the differences between their regional dialect and OpenStreetMap English (or indeed that en_OSM even exists). Localization into regional English dialects should help here, but it is tricky. On the other hand, such localization can hinder cross cultural communication if mappers donāt have to contend with the real en_OSM tag values, only localized strings in their particular en_* dialect.
When localizing into non-English languages, it is generally clear if you are looking at English or your local language. āStraĆeā is clearly German and āRoadā is clearly English. Of course this isnāt always the case. āTagā could be English or German and means a rather different thing in each case. This same thing can happen between English dialects.
The term ācamp siteā has a different meaning in American English than it does in British English (and in en_OSM). An American English speaker can easily make the mistake of tagging camp_site
where the correct tag is camp_pitch
because of this subtle difference in meaning. An en_US localization labelling camp_site
as ācampgroundā and camp_pitch
as ācamp siteā would help prevent incorrect data entry by unaware American English speakers. However, if such a localization were to completely hide the underlying en_OSM tag values then communication between those that speak American English and those who speak a different dialect would be confusing:
en_US mapper: āI added a camp site to this campgroundā
en_GB mapper: āAre you sure? It looks to me like you added a camp pitchā
en_US mapper: āNo, I definitely added a camp siteā.
ā¦ both mappers unaware of the localization and the different meanings of the term in their respective dialects
To me it seems clear that when it comes to English dialects, neither strict localization or strict adherence to en_OSM are good options. I think an ideal English dialect localization would be something like this:
- Stick as close as possible to en_OSM while ensuring terms will be well understood
- Change a term if it will be misunderstood or confusing in the regional en_* dialect
- Where a term differs between the regional dialect and en_OSM, always display the en_OSM term as well. For example an en_US UI might display:
- Campground (en_OSM: camp site)
- Campsite (en_OSM: camp pitch)
This obviously would require more UI design consideration than a typical localization, but itās the only way I can think of to work against cross-dialect misunderstanding and incorrect data entry.