Copyedit English localization as American English #5029
Conversation
Copyedited the entire English localization. The English localization now uses American English vocabulary and spelling throughout, but without unduly applying U.S. legal norms to interface elements that apply to the whole world.
|
I've only glimpsed at this but it's immediately obvious that you've gone far beyond just fixing british/american spelling variation to make editorial changes around how things should be presented and I'm not sure it's wise to do all that in one PR as it will be very hard to review. |
|
Agreed, I’m writing up some comments that annotate things that don’t quite fit the bill, so we can figure out what should get split out. |
There was a problem hiding this comment.
As you can see, spelling is the least of our concerns. I could split out a scaled-back PR that only replaces British spellings with American spellings, but I would still advocate for a number of other changes to resolve key misunderstandings. Alternatively, we could split up this PR section by section, isolating the Nominatim and map key integrations that will probably be more contentious.
| grave_yard: "Grave Yard" | ||
| fuel: "Gas Station" | ||
| gambling: "Gambling Hall" | ||
| grave_yard: "Graveyard" |
There was a problem hiding this comment.
“Graveyard” is normally a closed compound, but this file and id-tagging-schema both had it as an open compound, “grave yard”. There are a bunch of examples of this throughout the file.
| theatre: "Theatre" | ||
| toilets: "Toilets" | ||
| theatre: "Theater" | ||
| toilets: "Restroom" |
There was a problem hiding this comment.
I realize amenity=toilets can technically refer to an outhouse in the woods, but “toilets” is impolite in American English, bordering on vulgar.
There was a problem hiding this comment.
On the other hand, if we want to lean into British quirkiness, how about “Water Closet”? 😉
| "yes": "Amenity" | ||
| boundary: | ||
| aboriginal_lands: "Aboriginal Lands" | ||
| aboriginal_lands: "Indigenous Boundary" |
There was a problem hiding this comment.
This is usually seen as a more inclusive term than “aboriginal”, which is technically a synonym but has an Australian connotation.
| suction_point: "Emergency Suction Point" | ||
| water_tank: "Emergency Water Tank" | ||
| siren: "Siren" | ||
| suction_point: "Water Drafting Site" |
There was a problem hiding this comment.
“Drafting site” is firefighter’s jargon but the only remotely English term I could find in the real world for a Saugstelle.
| tertiary_link: "Tertiary Road" | ||
| track: "Track" | ||
| tertiary_link: "Tertiary Link Road" | ||
| track: "Land Management Road or Vehicular Trail" |
There was a problem hiding this comment.
A “track”, unqualified, is something a deer forges in the woods, a trail of shoeprints in the mud, or maybe the imprint of a farm tractor cutting through the fields. Qualified, it could be a railway=track (train track), leisure=track (running track), or highway=raceway (racetrack), but definitely nothing to do with highway=track.
highway=track is the only tag for which I had to equivocate on the description. This tag is essentially used for two different purposes:
- Special-purpose roads built for a productive land-based activity (forestry roads, mining roads, levee roads, fire roads, dirt roads on a farm)
- In some regions, quasi-roads used by offroading vehicles for recreation
There isn’t a concise, obvious word for the first purpose, let alone both at the same time. id-tagging-schema uses “Track / Land-Access Road” as a grand compromise, but this is a word salad that only makes sense to someone who managed to read all of openstreetmap/id-tagging-schema#288 and the preceding mailing list threads.
I considered a number of terms of art for this tag. The two that stood out to me are “land management road” and “resource road”. These are established albeit obscure terms for use case (1) in the U.S. and Canada, respectively.
An American user probably won’t have encountered the phrase “land management road” per se, but they’ll hopefully recall the Bureau of Land Management and the various activities allowed on BLM lands. But they might misunderstand “management” to imply that the road is actively maintained. Appending “vehicular trail” would counter that assumption.
The current description is very long. I’m inclined to switch to the Canadian “resource road”, which is shorter. It’s also more enigmatic, so the user is less likely to assume anything in particular about the road.
| fuel: "Filling Station" | ||
| gambling: "Gambling" | ||
| grave_yard: "Grave Yard" | ||
| fuel: "Gas Station" |
There was a problem hiding this comment.
Some time ago, I was showing someone OSM; they were unfamiliar with this archaic term and misread it as “filing station”. It was during tax season, so they thought it the feature was miscategorized as a government office. More recently, I was chatting with someone who snarked that it has something to do with a cafeteria.
| carpet: "Carpet Store" | ||
| charity: "Charity Store" | ||
| cheese: "Cheese Store" | ||
| chemist: "Drugstore" |
There was a problem hiding this comment.
“Chemist” is a notorious string among the U.S. mapping community. It’s quite difficult to fathom why a pharmacist would set up shop inside a chemistry lab. On the other hand, I hope Commonwealth English speakers who wind up seeing the replacement won’t think it refers to a vendor of illicit drugs. Personally, I haven’t been a fan of equating drugstores with shop=chemist (openstreetmap/iD#3213), but that’s a done deal now.
| @@ -2266,7 +2266,7 @@ en: | |||
| welcomemat: | |||
| url: https://welcome.openstreetmap.org/ | |||
| title: For Organizations | |||
| description: With an organization making plans for OpenStreetMap? Find what you need to know in the Welcome Mat. | |||
| description: Do you belong to an organization that wants to work with OpenStreetMap? Find what you need to know in the Welcome Mat. | |||
There was a problem hiding this comment.
The old wording might read better in some other dialect of English, but it never felt grammatical to me because it starts with a preposition phrase and lacks a subject. The new wording more closely matches the masthead on the Welcome Mat site itself.
| Local Chapters are country-level or region-level groups that have taken the formal step of | ||
| establishing not-for-profit legal entities. They represent the area's map and mappers when | ||
| Local chapters are national or regional groups that have taken the formal step of | ||
| establishing nonprofit legal entities. They represent the area's map and mappers when |
There was a problem hiding this comment.
At least one of the local chapters, OpenStreetMap U.S., is a nonprofit organization. It is not a not-for-profit organization. The two terms are legally quite distinct, and mixing them up could dissuade some people from joining or donating to OSMUS.
There was a problem hiding this comment.
Your change seems to claim that all local chapters are nonprofit legal entities. Even if this were true at the moment - which I'm not sure about -, it is not required that a new local chapter must be nonprofit. The LC template agreement only says they must be not-for-profit. Your change is therefore misleading. It may well be that OSM US are exceeding the requirements for a local chapter in this regard but I think that the OSM US website would be the correct place to mention that.
There was a problem hiding this comment.
Well it already says that unless you're going to argue that not-for-profit and nonprofit somehow have different meanings?
There was a problem hiding this comment.
As I understand the U.S. situation, nonprofit and not-for-profit are both types of tax-exempt; nonprofit isn’t not-for-profit-deluxe. The U.S. situation informs how American English would interpret this string, whereas the template agreement obviously has to respect UK legalities.
But I guess we don’t want to detract from the explanation that follows – the user will care more about the service provided than the legal status in this context. Should we avoid either term and just say it’s a legal entity, unqualified? If we need to emphasize that these entities are noncommercial, we could use that term.
| car: "Car Dealership" | ||
| car_parts: "Car Parts Store" | ||
| car_repair: "Car Repair Shop" |
There was a problem hiding this comment.
Maybe this is regional, but it seems to me that "Auto" or "Automotive" is far more common than "Car" in the context of parts and repair. i.e. auto parts store, auto mechanic, automotive repair. On the other hand, "Car Dealership" definitely sounds right to me. I don't commonly hear or read about auto dealerships or automotive dealerships.
There was a problem hiding this comment.
There are a bunch of possibilities here – even just “Mechanic”. The main thing is that shop=car_parts is a “store” while shop=car_repair is a “shop” (as in “workshop”).
Co-authored-by: Zeke Farwell <[email protected]>
|
I know this is well-intentioned and addresses a genuine technical issue, but I'm a little sad about this. It's essentially squashing one of the appealing aspects of OpenStreetMap's individuality in favour of unintentionally reinforcing some low-level cultural imperialism - i.e. the notion that the lingua franca of open source software is always American English. Having the project default to British English was always one of the little markers of "OpenStreetMap is different", a bit like Ruby's social norms being essentially Japanese. The real issue appears to be a TranslateWiki/Mediawiki bug as linked in #4975, and I wonder whether some work around the osm-website/TranslateWiki interface (about which I know precisely nothing) could bypass that. Of course, I haven't contributed to openstreetmap-website since approximately 17761 so my viewpoint means That aside, I would suggest splitting the PR into "pure UI changes" and "tagging-related changes", because doing things like redefining Footnotes
|
|
To be fair to @1ec5 he is following through on @gravitystorm saying that en should be US and the en-GB translation should be the British version. That said I think this is pretty much unreviewable as it goes so far beyond simple spelling and there is so much here that I would take issue with that I doubt we could ever converge on an acceptable version in a reasonable time frame. What I'm not sure of is what a reviewable version would look like. |
|
I'd just like to comment on the classification terms, if I may, having contributed many of them. Feel free to ignore me. Keeping the English version quite close to the OSM tag name has always been somewhat intentional. |
Link to #4975 (comment) where this was stated for convenience.
Even though I'd be very happy to see many of these changes merged, I tend to agree that this PR should get split out into more manageable chunks. Some of these changes would be very beneficial to new US mappers as they learn OSM tagging terminology. When a particular term has a different meaning or is very rare in US English it can lead to misunderstandings and incorrect data entry. Many of the other changes are more subjective, changing a word that is less common in US English to one that is more common. I'd hate to see the consequential changes delayed or not happen at all due to disagreement over less important ones. A consequential example: The en_GB term "camp site" translates to en_US as "campground" and the en_GB term "camp pitch" translates to en_US as "campsite". This would be very helpful to clarify in an en_US localization of the site! A not so consequential example: "waste basket" vs "trash can". Trash can is probably the more common en_US term, but waste basket is also used. There might be a slight semantic difference and "waste basket" might be a bit out of fashion, but I don't think picking one or the other would have much impact on a new mapper's understanding.
I can relate to this. I've learned many new terms through OSM that I wouldn't have otherwise in my native US English. A common "mapping speech" (sometimes I call this the en_OSM dialect of English 😀) is certainly crucial for communication. However, doesn't the fact that these terms are localized into many other languages already run a bit counter to this idea that mapping speech is expected on osm.org? I could see an argument that the mapping speech term should be shown along side the localized term but that's not currently what happens when viewing the site in a language other than English. |
| pitch: "Sports Pitch" | ||
| pitch: "Playing Field" |
There was a problem hiding this comment.
I'm not sure if this works. Though leisure=pitch is used for many "sports fields" or "playing fields", it is also used for tennis courts, basketball courts, hockey rinks, and perhaps other sports areas that aren't fields. It seems that in British English the term "pitch" covers all these area types but we don't have an equivalent umbrella term in US English.
There was a problem hiding this comment.
In standard British English, can “pitch” actually refer to a badminton court or horseback riding arena? I thought that was “mapping speak” anyways. We can make it “Sports Field or Court” if that would be more understandable. I was trying to avoid equivocation in these strings, but this is a relatively good case for conjoining two terms.
There was a problem hiding this comment.
The Wikipedia page on pitches includes badminton and various other court sports. Of course the article "needs additional citations" so who knows. The Cambridge & Collins dictionaries both define "pitch" as an area with painted lines or markings for playing a sport. This sounds to me like a court would fit this description since a specific surface type is not stated. They both include hockey (played on an ice rink not a field) as an example. I'm not sure exactly what the term "pitch" covers in British English, but it does seem to have broader meaning than "playing field" which typically indicates a grass or turf surface. I don't think I've ever heard a basketball or tennis court referred to as a playing field, but maybe it is technically still correct when discussing the rules of the sport and the "field of play".
There was a problem hiding this comment.
"Sports Pitch" is a confusing term to me as an American English speaker, even if there are nuanced differences I think Playing Field is clearer overall.
I can empathize with this. I don't enjoy feeling like my culture is getting pushed onto others. I'd be perfectly happy to have an en_US localization that isn't the default if the maintainers want and are able to set things up this way. |
I completely understand. Personally, I like the occasional quirky Britishism, if it’s just a difference of spelling or diction. And I’m a huge fan of the Oxford comma (sometimes odiously branded the Harvard comma). But there are many problematic tag translations that we should have some solution for. I’m here because, a few weeks ago, we had an impromptu mapping campaign around that most American of institutions, the drive-through liquor store, and a bunch of us saw “Off License” and thought it was a bug. Maybe a misplaced license agreement string? I honestly have no problem with relegating the Americanisms to en-US.yml if we can ensure that works with our translation management system. The CLDR default content locales cause problems for other languages too, like Portuguese. But Translatewiki.net has taken a hard stance that they want to follow Standards. One workaround would be to maintain the American English localization manually outside of Translatewiki.net, but the maintainers would have to review updates manually too.
If that’s what we want, then this diff will get even bigger. For better or worse, this localization is already taking liberties with some strings to sound more British and less Mapper, such as Maybe we could add a tooltip to each row of the search results and map key that indicates the raw tag, just like when you hover over a linked element in the element inspector. That could have the educational effect you’re expecting – even if the user speaks Dutch. 
Yes, I really appreciate all of you taking the time to look at this draft so far, but I really didn’t intend this to be a final product to ram through. This maximalist changeset gives native speakers an opportunity to discuss individual changes line by line, and then we can figure out how to stage the changes in more digestible chunks for the maintainers to review. Many of the changes are inessential, as @zekefarwell points out: if we can’t identify any strong reason to change a string, we can leave it alone. We could decide to keep the “shops” along with a few “dealerships” and “parlors” for a quaint, nostalgic feel. How about I start by splitting out separate PRs for some things that are clearly bugs, regardless of dialect, such as |
| tax_advisor: "Tax Advisor" | ||
| telecommunication: "Telecommunication Office" | ||
| tax_advisor: "Tax Advisor Office" | ||
| telecommunication: "Telecom Office" |
There was a problem hiding this comment.
I think that in this case Telecommunication Office is just as clear, and better matches the tag.
| beauty: "Beauty Shop" | ||
| bed: "Bedding Products" | ||
| beverages: "Beverages Shop" | ||
| bathroom_furnishing: "Bathroom Furnishing Store" |
There was a problem hiding this comment.
I recommend Bathroom Design Store to match shop=kitchen below.
| atm: "ATM" | ||
| bank: "Bank" | ||
| bar: "Bar" | ||
| bbq: "BBQ" | ||
| bbq: "Barbecue" |
There was a problem hiding this comment.
I think BBQ is just as clear, and it matches the tag.
There was a problem hiding this comment.
I was under the impression that “BBQ” only refers to a cookout or the dish, whereas the equipment would only be called a “barbecue” or a “grill”. But maybe this is too pedantic? Ironically, for the dish, cuisine=bbq has been deprecated in favor of cuisine=barbecue.
There was a problem hiding this comment.
Oh wow I've never considered that distinction before but you may be right. "Barbecue" may indeed be more appropriate for the grill itself. I do not have a strong preference here.
| garage: "Garage" | ||
| garages: "Garages" | ||
| greenhouse: "Greenhouse" | ||
| hangar: "Hangar" | ||
| hangar: "Hangar Building" |
There was a problem hiding this comment.
I usually do not hear fellow American English speakers say "building" after "hangar."
There was a problem hiding this comment.
Yeah, this came from id-tagging-schema, which needs to distinguish between the presets for aeroway=hangar and building=hangar. But that distinction is probably less important in the context of these search results.
| hospital: "Hospital Building" | ||
| hotel: "Hotel Building" | ||
| house: "House" | ||
| houseboat: "Houseboat" | ||
| hut: "Hut" | ||
| industrial: "Industrial Building" | ||
| kindergarten: "Kindergarten Building" | ||
| manufacture: "Manufacturing Building" | ||
| manufacture: "Industrial Production Building" |
There was a problem hiding this comment.
The building=manufacture documentation says this is narrower than building=industrial but broader than building=factory, encompassing storage buildings. I’m not sure why id-tagging-schema felt the need to call it something longwinded; “Manufacturing Building” seems OK given the other overlapping terms.
| handicraft: "Handicraft" | ||
| hvac: "HVAC Craft" | ||
| metal_construction: "Metal Constructioner" | ||
| handicraft: "Handicraft Workspace" |
There was a problem hiding this comment.
This Wikipedia page offers some alternative names. Handcrafting Workspace or Artisan would sound more natural to my ear.
| construction: "Highway under Construction" | ||
| corridor: "Corridor" | ||
| construction: "Highway Under Construction" | ||
| corridor: "Indoor Corridor" |
| passing_place: "Passing Place" | ||
| path: "Path" | ||
| pedestrian: "Pedestrian Way" | ||
| platform: "Platform" | ||
| pedestrian: "Pedestrian Mall" |
There was a problem hiding this comment.
I've never heard "Pedestrian Mall" in the U.S. Perhaps Pedestrian Road would fit better.
There was a problem hiding this comment.
“Pedestrian mall” has historically been the preferred term in American English, as seen in Google Books Ngram Viewer. However, I appear to be dating myself: “pedestrian street” is more popular in the last several years, and “pedestrian zone” is also becoming common. That’s the term Wikipedia uses too, to avoid favoring American/Australian terms over the British term “pedestrian precinct”. “Pedestrian road” appears to be very rare.
I think “pedestrian street” would be intuitive and pretty close to your suggestion. “Pedestrian zone” would be problematic because it too strongly suggests an area, whereas this tag can validly appear on a way.
There was a problem hiding this comment.
Yes, now that you say it I think "Pedestrian Street" is even better. Good idea re: ngram!
| leisure: | ||
| adult_gaming_centre: "Adult Gaming Centre" | ||
| adult_gaming_centre: "Adult Gaming Center" | ||
| amusement_arcade: "Amusement Arcade" | ||
| bandstand: "Bandstand" | ||
| beach_resort: "Beach Resort" | ||
| bird_hide: "Bird Hide" |
There was a problem hiding this comment.
This should be Bird Blind in en-US.
| jewelry: "Jewelry Shop" | ||
| kiosk: "Kiosk Shop" | ||
| kitchen: "Kitchen Shop" | ||
| hifi: "Hifi Store" |
I’ve copyedited the entire English localization, fixing a number of spelling, capitalization, and grammar issues. The English localization now uses American English vocabulary and spelling throughout.
Rationale
Ideally, the
enlocalization would be some flavour of “international” English, presumably an amalgam of non-American dialects. However, most user agents follow the industry standard of treatingenas American English anden-001as international English. I don’t think we can expect Translatewiki.net to supply a separateen-USlocalization anytime soon, since MediaWiki has essentially declined to distinguish betweenenanden-US. Theen-GBlocalization will continue to be written in British English, but Australians, Canadians, Indians, New Zealanders, South Africans, etc. will see Americanisms until Translatewiki.net adds separate localizations for their dialects, which fortunately would be more feasible.Scope
These changes affect user interface strings across the entire project. Most of the changes relate to vocabulary, but I took the opportunity to fix some glaring issues, such as tag names that got mixed up.
The date format and quotation marks follow the American standard. I refrained from addressing other typographical issues, such as curly quotes, or using (or avoiding) the Oxford comma more consistently; those things can happen in a followup PR. Because many strings can refer to features anywhere in the world, I’ve also refrained from unduly applying U.S. legal norms to these strings; in fact, I’ve globalized a number of strings that had previously made regional assumptions.
Process
I went through the file line by line, pausing every so often to avoid semantic satiation. Then I searched for some Britishisms like -our and -ise.
Many of the strings are applied to Nominatim search results or the map key. Mappers will undoubtedly care that these strings retain some resemblance to the terms used elsewhere in other OSM software. For the most part, I followed the preset names in the iD tagging schema’s (American) English localization, figuring that a user should see something similar on the homepage and the Edit tab.
Caveats
Some terms simply don’t have a single household word across the English speaking world – or even across the U.S. – while others have no real word in the real world because of artificial OSM tagging distinctions. At some point, id-tagging-schema started compromising by tacking on alternative names with slashes, but a more general term would be more appropriate for these strings. Since this project only identifies existing features rather than helping users choose tags for a new feature, I took some liberties in order to avoid verbose, ambivalent strings.
I’m aware that many of these changes may break longtime users’ intuition and muscle memory. Many users who don’t speak English as a first language probably still use the English localization anyways, and some may be familiar with the raw OSM tagging vocabulary that previously was reflected in these strings somewhat haphazardly. It may be necessary to scale back these changes somewhat, but I’ve started with a more maximal set of changes in order to document the tradeoffs we end up making.
On that note, this is a draft until I’ve gotten a chance to annotate some tricky decisions that I’d like feedback on.Fixes #4975.