Canada + USA ≠ North America

As a member of NaturaLista, the Mexican iNat network, I've noticed that some English-speaking users have recently begun to mark common names for some species as valid in "North America". What these users may not be aware of is that, when using this geographic mark, the common English names overrule the vernacular names in other North American languages. This is the case in Spanish, and I assume it is the same problem in French and Dutch.

Example:

The species Lythrum salicaria has the common Spanish name "arroyuela", without geographic indication.
It has the common English name "Purple Loosestrife", marked as valid in North America.
NaturaLista, as well as iNat in Spanish, display the English name instead of the Spanish one.
Even if the Spanish name were marked as valid in Mexico, it would be overruled by the broader area of North America. Also, the English name would still be valid in Quebec, in Panama, in Sint Maarten etc.

My suggestions:

  • Stop using the "North America" tag as meaning only Canada and the US. It is misleading and Anglocentric.
  • Create a location defined as "English North America", "Anglo-America" or something similar. Consider that the first would also include Belize and the English-speaking islands, and the second one Guyana, the Falkland Islands, and South Georgia and the South Sandwich Islands, additionally.
  • Invert the priority of the validity of common names, so that the names defined for smaller areas overrule the names defined for bigger ones.

What do you think?

Publicado el miércoles, 22 de agosto de 2018 a las 03:38 PM por bodofzt bodofzt

Comentarios

">Even if the Spanish name were marked as valid in Mexico, it would be overruled by the broader area of North America.
Check the page again, I don't think that's true. I set the arroyuela as the default name for Mexico. I then adjusted my site settings to display the entire site in Spanish and cleared my "common name place" settings too. Arroyuela is now displayed first for me. https://www.inaturalist.org/taxa/61321-Lythrum-salicaria

fyi @cmcheatle @bobby23

Anotado por bouteloua hace mas de 5 años

Lower levels of geography when entered take precedence for sure.
https://www.inaturalist.org/taxa/14995-Dumetella-carolinensis
Has Gray Catbird for North America, and Grey Catbird for Canada. My prioritize names is set to Canada, and I see Grey Catbird as the display.

I suspect many of the "North America" entries were done by a now former curator.

Unless it excludes Quebec (and an argument can be made for New Brunswick), an "Anglo North America" area is not a great idea, plus many species are differently named in Canada vs the US due to spelling.

Hopefully I don't forget, but I always try to enter US and Canada as separate entities.

Ideally regional use names should not be allowed to be entered at a higher level than nation. It is also a problem when "Europe" is entered, and it overrules all the translations entered for non English names.

Anotado por cmcheatle hace mas de 5 años

I'm pretty sure everything Cassi and Chris said is correct , but choosing what common name to show people is pretty complex, so maybe we're just not replicating what you're experiencing, Bodo. Let's stick with the case of https://www.inaturalist.org/taxa/61321-Lythrum-salicaria. Keep in mind that the choice of common name is a combination of some things you control, like your "names place" setting, your locale, the site you're using (e.g. iNaturalist.org vs naturalista.mx); and some things site curator control, e.g. what names have been added, what places they've been added to, what their priority is globally and within a place. So in order to replicate what you're reporting, we need to know

1) What locale / language you're using
2) What your "Names place" setting is
3) What site affiliation is
4) What URL you're looking at
5) What common name you're seeing vs what you're expecting to see

Here's what I'm experiencing:

1) Locale set to es-MX (Mexican Spanish)
2) Names place set to Mexico
3) Site affiliation is iNaturalist.org
4) Looking at https://www.naturalista.mx/taxa/61321-Lythrum-salicaria (though I get the same result for https://www.inaturalist.org/taxa/61321-Lythrum-salicaria)
5) Expecting to see "Arroyuela (Lythrum salicaria)" at the top and that's what I see

Anotado por kueda hace mas de 5 años

Thanks for answering, everybody!
Indeed, I checked that what Cassi says is true. I just added Mexico as a geographic marker for Pieris rapae and it changed to the Spanish name instead of "Cabbage White". IIRC it used to be different, as I had tried to do that a few months ago and it didn't work that time.
Still, I believe it is an unideal corrective measure, as you would have to include all of the places other than English-speaking North America for the names to be displayed correctly. Why not stop using North America altogether?

Anotado por bodofzt hace mas de 5 años

Because generally, all English-speakers in North America probably use the same English name, and all Spanish-speakers probably use the same Spanish name. You could imagine the same thing happening with Spanish and Portuguese in South America. I'm still testing, but I think what you might have experienced is the place preference overriding the locale / language preference when "arroyuela" was the default Spanish name but it hadn't been added to Mexico. That seems like a bug to me, or at least something that needs improvement.

What would really help me is if you could provide the info I asked for above for a situation that still looks broken to you.

Anotado por kueda hace mas de 5 años

Melilotus officinalis https://www.inaturalist.org/taxa/57066/names
-Default is "yellow sweetclover" for Place: "North American incl. oceans"
-Has a common name in Spanish: "meliloto amarillo," but it's not added as default for any place

1) What locale / language you're using - Spanish
2) What your "Names place" setting is - Mexico
3) What site affiliation is - iNaturalist.org
4) What URL you're looking at - https://www.inaturalist.org/taxa/57066-Melilotus-officinalis
5) What common name you're seeing vs what you're expecting to see - "meliloto amarillo," but I see "yellow sweetclover" instead

Anotado por bouteloua hace mas de 5 años

Cassi - isn't that what you'd expect to see ? Mexico is a child of North America in the geography tree. The place names setting has the precedence, and yellow swetclover is the lowest (or highest - whatever way you describe it - it is position 0) rank name that is entered for North America. There is no data point that pairs or links Mexico the place and the Spanish translation in what is there.

If you were to blank out your names place, then the locale would kick in.

I'm not sure I see any use case for allowing continent level names. With the arguable exception of Australia, no continent is functionally unilingual. Yes many names are shared between the US and Canada were an entity covering that created, but there are not an insignificant number of differences across the border too.

Anotado por cmcheatle hace mas de 5 años

It's what I expect to see given how I understand the site to currently work. But what I would expect as a normal user with no knowledge of how iNat common names work: if I have my website settings in Spanish and my "names place" set as Mexico, I wouldn't expect I should see any English common names at all if there are Spanish names entered into the system.

Names should only have to be "set" for a particular place if there is a conflict between two places where that language is commonly spoken, right? e.g. if Spain and Mexico had different names for Melilotus officinalis?

Anotado por bouteloua hace mas de 5 años

Yes, but the technical approach also has to support displaying names in languages for which there is no system translation or locale. For example, if I want to see names in Swedish (why I would want to I don't know - they spell everything funny), I can only do it if the names place is set to Sweden for translations entered. There is no link that says "Swedish is spoken in Sweden so show Swedish names if I set my Place Names to Sweden". or example, 10% of the population of Finland speaks Swedish, the only way they can see the names in Swedish is to set their names place to Sweden.

There is no technical concept in the system that a place is linked to a language. Nor am I sure how you could do it technically given there are places with multiple languages - what would it be for India, Switzerland or South Africa.

Anotado por cmcheatle hace mas de 5 años

Thanks, Cassi, I got there on my own in a test env too. The fundamental issue is that a name's place is overriding locale, so a user who has a locale of Spanish and a place of Mexico still sees the North American English name even though a Spanish name is available, which is jarring. I think the intent in making it that way was to accommodate situations like New Zealand where the common name used by both English and Maori speakers is the Maori name, but that seems like more of an edge case than this one, and it can be remedied by making duplicate names in the English locale for those Maori names (this has already been done for a lot of NZ taxa).

Anyway, long story short, I'm experimenting with ensuring locale gets precedence over place... which means I'm sure someone else will be annoyed. Will probably post something to the Google group when I have something to show.

Anotado por kueda hace mas de 5 años

Ignorantcassi would expect that if a common name has been entered under a certain lexicon ("name language"), she should be able to choose that lexicon in her site settings--whether or not the entire website has been translated enough for her to be able to choose that language for the whole site ("website language").

edit to add: response intended for Chris's latest message, not Ken-ichi's. : ]

Anotado por bouteloua hace mas de 5 años

Ken-Ichi, if you reset the priority to locale first, how are cases like Canada going to be handled ? There is no Canada locale (or UK or Ireland etc), we have to use English. If that takes priority over place names - don't we lose our distinct names in favour of the US ones, which lets face it will always be the top priority English names.

Anotado por cmcheatle hace mas de 5 años

Chris, I'm aware of the issue, and I'll make sure locale gets priority within a place first. Since I can't think of a Canadian example off the top of my head, here's how it would go down for https://www.inaturalist.org/taxa/564969-Chamaenerion-angustifolium for people who have their locale set to English:

If you have no "Names place" preference set you'll see "fireweed," the global English default right now.

If you have your "Names place" preference set to the United Kingdom, you'll see "rosebay willowherb", the default for the United Kingdom (and the only English name in the UK).

If you have your "Names place" preference set to the United States, you'll see "fireweed," the global English default name.

Anotado por kueda hace mas de 5 años

I'm sorrry for the late response. I was running errands today.

I guess I still do not fully understand how names are implemented on the site. If I was a casual user (who happens to speak Spanish in this scenario), I assume that language setting would take precedent over locale. If the English name "Purple Loosestrife" was set to "North America", I assume I still would see "arroyuela" because my language is "Spanish" under settings and that would take precedent. I assume any curator who set English names to an entire continent (like North America/Europe) operated under that assumption as well and were not trying to be Anglocentric. Is that not the case? If not, shouldn't it be?

Anotado por bobby23 hace mas de 5 años

So, this is more a programing issue or page settings issue?

Anotado por aztekium hace mas de 5 años

I'm hoping it's a programming issue. See https://groups.google.com/forum/#!topic/inaturalist/P8iNMY0WYNM

Anotado por kueda hace mas de 5 años

Añade un comentario

Entra o Regístrate para añadir comentarios