Happy to have a go Mike, but have been unable to open the "Notes on population  the Taxon Common Name table.odt" file in its current format.

OK Mike, my first impressions are not good and I am about to undo the changes. The reason being that it seems to have started using older and less relevant common names in a number of cases. I don't have a problem with Felwort instead of Autumn Gentian (although many people wouldn't recognise the former) but I don't want to see Wild Hyacinth in place of Bluebell. I haven't taken the time to investigate why these particular results came out as they did, but for now I prefer the old way.

If I get time to do any detailed investigation I will let you know what I find out.

Sorry Mike, that file is still odt, not rtf

Mike

Having reimplemented your changes most things now look as they should (to my eye). There is however one glaring inconsistency which keeps annoying me. Recorder now reports records of Common Bent (Agrostis stolonifera) a very common grass species with the common name fiorin, which as far as I can tell is a very old name indeed and one which I had never encountered before.

I have tracked it down to the recorder 3.3 dictionary (surprise surprise), but when I try to edit the taxon details to put in the more familar common name (as I have with several other taxa successfully) I am informed that "You cannot edit this taxon. The rank sequence of its parent is lower or equal to the rank sequence position of its children. Therefore there are no valid ranks that can be selected. Please correct the rank of the parent and/or children first."

Any idea what this means?

Ah, I see a possible source of confusion here. I may not be talking about the recommended common name. The particular instance I have seen most recently is of a record entered recently, but apparently against the Recorder 3.3 list (we try not to use this list now, but it was entered using an older recording card). The TLIK is NBNSYS0000066313

As you suggest, reports supplying the recommended common name produce the correct result Creeping Bent, although after I installed the previous version of your changes they were returning Fiorin. So that much is fixed.

However in the observations hierarchy the record is listed as Fiorin (Agrostis stolonifera) and this is a new behaviour as far as I can tell. Also in the edit taxon details window, taxon names tab, the "use standard common name" checkbox is ticked and gives Fiorin as the standard name.

However I am a botanist and have been recording this species in probably the majority of my surveys for the last 15 years, for the last two or three years using Recorder 6 and for the preceding 12 years using Recorder 3.3, it seems unlikely that I would have failed to notice the name Fiorin before now had it been Recorder 3.3 standard. In fact I have just opened up a copy of Recorder 3.3, almost untouched since the day I installed Recorder 6 and it does indeed list both common names for Agrostis stolonifera, but crucially Creeping Bent is at the top of the list. I'm pretty sure Rec 3.3 would have used order of appearance as order of preference.

I appreciate that you haven't done anything to change the lists, but it looks like something in the way the content of the lists is reported in the Rec 6 UI has changed recently.

No Mike, that is not the case. I have a standalone copy of R6 to which I have not applied your changes and it reports Creeping Bent correctly. I am sure that the behaviour I describe above is a consequence of applying your script. But just to prove it I am going to undo the changes now to see what happens.

...And I can now confirm that, I have applied your restore script and the common name in the R3.3 list is now reporting correctly as Creeping Bent throughout the UI.

This suggests that whichever method you are using to select the actual common name (as opposed to the recommended one) from a list, is the wrong one, at least in this instance.

Going to leave things as they are for a while and try to determine which state I prefer.

R3.3 clearly had a mechanism for determining which was the preferred common name. What we need to establish is whether the export routine used to get the data ready for R6 took this into account and how R6 handled the import of that data I guess. I wonder if Stuart Ball could be of assistance here?

OK that seems to work fine at least for the various examples I have noted so far. I will let you know if I come across any other discrepancies.