Platform(s), such as mobile, website, API, other: Website and mobile
Description of need: Describe the iNaturalist community need that your requested feature addresses. Include screenshots, URLs, and other details to help us all understand the issue.
Feature request details: In detail, describe the feature you are requesting. This includes its functionality, where the feature is implemented, and what it might look like. Screenshots or mock-ups are helpful. The idea is to have a concrete and actionable request which the community can discuss and vote on. It might change through discussion, but itâs much easier to iterate and talk about something specific.
Note that I am using a spurious example to illustrate my request.
Cassida is a globally distributed genus of tortoise beetle. It currently has no common name on iNat.
I find a field guide for Australian insects that lists âshiny tortoise beetleâ as a common name for this species, and I want to add it.
I add the name, and it now appears globally for anyone viewing this species. This functionality makes sense.
I then reconsider this, as the name was only in an Australian guide, and Iâm unsure if the name is applicable/used in other countries. So I edit the name and set the priority to Australia.
The name still appears globally.
My request is therefore that, if only one common name exists for a taxon, and if a place has been set as the priority for that name, the name will only appear for that place; everywhere else, no common name will appear.
Iâll pre-empt potential comments on this thread by saying I do not want a discussion of existing examples of this issue.
there are many cases where a common name is applicable to the species in a taxon in one place, but not others. For example, what if only the Australian Cassida species are shiny, and species from other countries are not shiny? The name now becomes inappropriate and misleading as a global application
I see your reasoning, and I think I know the impetus for this request, but I donât think a common name being misleading is sufficient reason to exclude it. I donât think thereâs a necessity for forcing name exclusion on otherwise unnamed taxa for common names in the same language; regardless of accuracy, as long as the common name exists, it should apply. If weâre going to exclude names regionally (or at all) based on their misleading nature, some sweeping changes have to be made to how/what common names are applied. Have you thought of any other reasons?
It sets a precedent for excluding names based on regional application, e.g. someone could block the name âmayflowers and false Solomonâs sealsâ for the genus Maianthemum in parts of the southern U.S. and central America because the species that far south donât flower in May and the central American species donât have common names in English yet. Ergo, ânone of the names apply to X region, therefore I exclude them despite being in common use in the same language.â
iNat provides an interesting and fast way to pick up on and spread common names for taxa that lack them. I donât want other people deciding for me which common names Iâm allowed to see, if there isnât one existing.
the same argument can be made the opposite way/from my perspective; why should I have to see someone elseâs common name that is only used in that place and nowhere else, especially if it doesnât apply to the species/taxa anywhere outside that place?
If a name has broad application it can be applied broadly. Region blocking names is very different from showing a name in use within a language, as it prevents you from seeing something rather than suggesting it to you. In other words, those who add/edit names are given the privilege and freedom to block what I see, even if it would help me learn something I find interesting, or help me remember members of a group I am not familiar with. You donât have to see any common names if you disable them, although I would guess that what youâre asking is for a more broad problem rather than an issue you personally have with common name use. Setting scientific names as priority over common names is similar.
I want to see when any English common name is being used for a taxon, regardless of whether or not it is relevant to my region. I also think âsomething is better than nothingâ applies, especially in the context of citizen science. For someone using iNat for the first time, seeing their post identified as âshiny tortoise beetlesâ is a lot more engaging, meaningful, and informative than âsuggested ID: genus Cassida.â For now, I donât see any reason to prevent users from seeing this information, even if it isnât relevant to their region.
Perhaps, rather than forcibly region-blocking IDs, make it an option to limit perceived names to those within your region? Or, when displaying a restricted-usage common name, adding an asterisk to the end of the name with pop-up text when hovered over/clicked on explains the name was added for a different region?
Rather than suggesting that the region specific common name be blocked, why not suggest that there is a note that indiates thatâs itâs a regional name
Something along the lines of:
shiny tortoise beetle - Australia
Widespread common names are often initially just regional ones, but they expanded as people moved around and talked with each other. Iâm in the camp of letting the current situation stand as is, but if itâs an issue for some (as it seems to be), then rather than removing it for everyone not in said area, a simple note tacked onto the end of the common name would seem to solve the problem and have the benefit o f not removing it for people who would like to see it remain as it is.
I agree with this request, for a very simple reason. iNaturalist provides the option to limit application of a common name to a particular place. It also provides the option not to. If someone chooses the option to limit application of a common name to a particular place when they add that name, iNaturalist should honor that choice, and not âborrowâ that name to substitute for a missing name elsewhere.
If another community member feels that the same common name should also apply somewhere else (or globally), they are always free to add another instance of the name using different parameters edit that name to add another place (or places) to that name.
EDIT: my mistake, there cannot be more than one instance of the same name in the same lexicon (language). However, currently one can edit the name and add multiple places to it, including overlapping places. If the name was initially added as a global name, though, it seems to remain as a global name even if one or more place(s) are added later. One must delete and re-add the name with a place restriction to get it out of global status. And even then, the system may âborrowâ it for a global name if no other global name yet exists - the topic of this feature request.
The issue for me is that it is not always easy to be able to discern when a name is only valid for a specific region or not. Sometimes this is clear-cut and there are obvious instances, but many are not that way. It feels to me that having a more localized common name appear for users in other countries is the lesser of the two evils. But, I think it could be argued both ways.
Thereâs a lot of folks who donât care about common names, and while that is fine, that sort of line of thought doesnât really address the discussion here. The result of this conversation should be fairly treating common names in a sense that they are important and useful to a lot of people, even if scientifically speaking they are not.
Yes, this. Which to me is exactly the reason why iNaturalist should not be automatically second-guessing a user when they choose to restrict a name geographically. Common names are community-maintained, and automatically borrowing a local name to use as a global name, without community involvement, gets in the way of that process.
I agree that this proposal would give users more flexibility and agree with @jdmore 's point that
That said, I have a couple of questions about how this would work.
If this request is approved and is retroactive, many common names that users are accustomed to appearing (and perhaps using) on iNat may disappear for them. I think that this would be the case for names that have previously been specified for a specific country but applied globally. There are probably a decent number of common names that should indeed be global but were input for a specific region. I have no idea how many common names this might affect. But, it means that there would probably be a period in which a lot of curator activity is needed around common names to sort out which should be global and which should be local only. (an option might be to retroactively make all common names âglobalâ by default and then remove the global status only for those for which is it warranted?).
Because common names can be entered by any user, itâs likely that this system (which is more complex than the current one) would not be fully understood by some users. Users entering common names may not understand the distinction between âlocalâ and âglobalâ names and how they are applied, so I think this change would also likely lead to a need for more curator attention in the long run as well.
Lastly, I think itâs important to think out how this feature would interact with a userâs language settings. I think this feature will likely make the greatest difference for common names in languages that are used in geographically widespread areas. For instance, in the case of a language that is generally only used in one country, this setting (local or global) might not matter much. Itâs probably good for common names to be âglobalâ for that language and not restricted to just their country. For a widespread language (like my own, English) that is used in lots of countries, there might be more disputes and/or confusion about what should be global vs. local. The change would also likely cause more impacts in larger, more diverse, higher order taxa and potentially for invasive species. If the change is implemented, I think it will need to be accompanied by some clear guidance for curators in different languages about how to implement.
We discussed this request today. Implementing this functionality would be a pretty heavy lift and introduce complexity to the way names work now (as in there must always be a global common name), and potentially cause a lot of current names to not appear for people. We didnât feel the benefits would be worth the development of this functionality.