Common names are shown in many different languages while batch editing

Whenever I batch edit a group of observations (via https://www.inaturalist.org/observations/alexis_orion), The common name field shows names in many langages, including the language I have set in my account settings (english). Earlier, I was editing a batch of around 100 observations, and I got common names in English, French, German, Italian, Spanish, Russian, and a couple I couldn’t recognize.

batch-edit
Has any one else seen this? I have been seeing this for quite a while, and I haven’t noticed a pattern.

I think some of the older pages dont honour one’s choices of Place for common names, and the reordering of common names on the taxonomy page, and the formatting of common names (as different from the case in the original). For instance, guides, batch edits and filling in IDs.
But it has been too insignificant for me to bother tracking details of all instances - I just assumed that when pages will be updated these will be brought back into line …

1 Like

Made an issue here, for what it’s worth: https://github.com/inaturalist/inaturalist/issues/2645

As this is pretty minor and not necessarily a bug but more of a design decision about exactly what should be shown there, we’re not going to fix this in the current batch edit tool but revisit when designing a new one.

I’m a little skeptical that a “design decision” would result in the same species sometimes being named in English and sometimes in Czech:

Maybe the follow-up question is how does the species_guess get set to something non-English when I’m definitely not using anything other than English/scientific name to enter the species?

1 Like

Mine often show up in Spanish - but my own default is always English.

I see the Github issue has been closed and deemed “not worth fixing”. I think this is more widespread than just the batch edit though. As reported by others, seemingly random languages for vernacular names appear in the emails as well. Even on the taxon pages this issue occurs. I see the French “Bleu Commun d’Europe” as the page title for that taxon, for example.

I checked my account settings and see my localization of common names was set to “North America (Continent)”. I probably picked that once upon a time as it is at the top of the list and I equated that with US English. I guess I am getting the Québecois I deserve!

So it seems like choosing large regions, sometimes even including oceans, can cause this. Switching to the United States as a country solved this particular taxon page for me, but maybe I will start seeing more Spanish and Tagalog from now on? I think the common names should be based on the interface language AND the region, rather than just the region.

The github issue that was deemed not worth fixing was whether to use species_guess for the names on the batch edit page. In theory species_guess is a defensible design choice for that field.

The actual problem, which was not addressed in the github issue, is that somehow species_guess is getting set in languages that don’t make sense. For example, some of my observations have the species_guess in Czech, but I certainly didn’t enter the name in Czech. The example Tony gave shows one of his set in Chinese, but I’m willing to bet he didn’t enter the name in Chinese.

Seeing “Bleu Commun d’Europe” is not the same problem since it has nothing to do with species_guess. It’s not even an error at all in the sense of a issue with the code. Rather, someone has set “Blue Commun d’Europe” as the preferred name for North America, so you should see that name if your account is set to North America.

If someone has set a Spanish name or Tagalog name as the preferred name for your place, then yes, you would see those names. It’s not a bug, that’s how the system is intended to work. This is a problem with users associating names with places, either because they want to see their preferred name or because they don’t understand how name-place associations work.

They’re based on both already, but place has priority over interface:

(2 could be amended to say “If the user has not specified a place priority for their names or there is no name associated with their place, the primary name entered in the language the user is running the site in”)

1 Like

Never said it was a bug, I just think the feature is wrong ;)

On the settings page, it says “Prioritize common names used in this place.” I have never interpreted that as something related to the actual language, just as the particular name used there. I.e. not the British name but the American one. “Prioritize” also makes perfect sense in that interpretation, whereas what it does in reality is just overrule the interface completely. I really don’t see why anyone would want to show names in a different language than that of the interface, but now that I know I can actually remove that setting it won’t bother me again.

I think calling that setting “Display common names in the language used in this place.” would be better.

Absolutely people do it, the first use case is for situations where the site is not translated into their language, so this way at least they can see the common names in their language, even if forced to use the site in something else.

It may also simply be a personal preference, I often run the site itself in Danish, but have my place names prioritized to Canada, because many of the North American species either don’t have a Danish translation or because most of the Danish common names I learned and remembered are for species found there.

1 Like