Thank you, I think this puts me in the right direction. So here is what I have so far.
In the interest of speeding things up, I created a small userscript (to be used with TamperMonkey / GreeseMonkey), that adds this “WikiSpecies: Sync Translations” link that you’ll see on the right:
(I’ll publish the script when I fixed some remaining bugs.) When I click the link, it fetches the translations from Wikispecies using the Wikimedia API. These read-only requests don’t even need an API key. Then it compares what it sees in the table and suggests fixes in the “Actions” column, and it adds new columns as well, with an action to add them (just takes me to the pre-filled form).
This is a lot faster than entering values through the form manually, less prone to copy-paste errors, and I add the source link to the description field. However, nothing is done until I click, and I have a chance to manually review things before entry. For many taxa, these are well established names that I know are widely used in textbooks and other literature.
For others, especially species, I wouldn’t know the name myself, so I’d look it up in Wikipedia. If there is an article already with photos and references, I’d just trust it without spending too much time looking at sources. Sometimes, there is however no Wikipedia article, but I can still find the name in my own books, or online sources: scanned books or similar.
In cases where there is no Wikidata entry, I’d prefer to add the translation to Wikidata first, with a reference, and then do the import using my tool. This has two advantages over importing to iNat first:
- Other sources might use Wikidata, and I think it has a higher chance of experts stumbling on it and fixing any mistakes I made, or updating the translation as necessary.
- I’d like to avoid adding the name to iNat, and then have it appear in Wikidata later, with a reference back to iNat as a source of truth. Like you said, it is better if iNat delegates the naming problem to somewhere else, and I believe Wikidata can be a good place for cases where there’s no “official” source.
I have some old books I plan to go through and check if the names can be imported, but for now I’m just fixing higher level taxa, like Fabaceae in my first example.
A side note, I’d prefer to use iNat, the website and the app, in English, and have only the common names show up as preferred in some location. Sadly, this doesn’t seem to work for all species, and I haven’t figured out what this depends on. For some species, the Hungarian common name would be shown even when the website language is set to English, for other taxa I have to change the website or the app locale to Hungarian to see the Hungarian common names. Yet other times, the name is shown differently in a list view vs. when I click the observation. Those are I assume different bugs that need to be dealt with separately, but for now a workaround is to change the site language.
Another side note: iNat “lexicons” don’t seem to use ISO language codes, while the “vernacular names” from Wikidata only use ISO codes, so mapping the two gets tricky. Even worse is that I can’t even map the languages by their English name easily, since e.g. iNat uses “Chinese (traditional)” (and lexicons.chinese_simplified
), while Wikidata uses “Traditional Chinese” (and zh-hant
), and similar issues.
Not wanting to maintain a lexicon-to-ISO-code mapping myself, for now I’m just abusing the language selector on the bottom of the side, which does use ISO language codes, and conveniently maps them to the language as it is displayed in the common names table. It doesn’t cover all lexicons, but it covers the ones I care about, so I call “good enough” and move on. But it would be nice if (a) iNat API provided a list of available lexicons, so I wouldn’t need to scrape the dropdown in the form, and (b) if the iNat lexicons were mapped to ISO codes for the language that the lexicon is based on. This would especially be useful for languages like Spanish, Portuguese, French, English, etc. which are used in many countries.
Lastly, sorry for the long answer, and thanks for the input. I got some useful information on this post, most importantly that I shouldn’t pursue any bulk-import but I would still like to make it easier to add more common names.