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”)