EDIT

NomenclaturalCodeEdition entry names are pure enum "names" not used for anything else. So we can rename them but there is no big need for this as they should never be shown to the user in anyway. Having all the same prefix has a certain advantage for sorting. Needs discussion.

This differs from NomenclaturalCode, where the abbreviation is also used as a title that is shown to users (but there we only use the current code abbreviation for pratical reasons.

Andreas Müller wrote:

NomenclaturalCodeEdition entry names are pure enum "names" not used for anything else. So we can rename them but there is no big need for this as they should never be shown to the user in anyway. Having all the same prefix has a certain advantage for sorting. Needs discussion.

This differs from NomenclaturalCode, where the abbreviation is also used as a title that is shown to users (but there we only use the current code abbreviation for pratical reasons.

These "practical" reasons lead to impractical result, as shown in this screen shot:

There are indeed two problems as there is no way to get the correct representation of the code edition from one of both enums.

1. For many current codes the NomenclaturalCodeEdition enum name is the only source for the correct code acronym, like "ICN"
2. There is no way to get the correct code acronym for historic editions, as these are completely missing in the cdm.

Suggestion: We should extend the NomenclaturalCode by year range dependent representation, an additional getLabel methods would have a second paramter:

getLabel(Integer year); 
getLabel(Language language, Integer year); 

that is NomenclaturalCode.ICNAFP.getLabel(2011) would return "ICN", whereas NomenclaturalCode.ICNAFP.getLabel(2005) would return "ICBN"

But I do not understand what we need the abbreviation for. It is really an important information to show the abbreviation of the code? In the TaxEditor we do it the following way:

which to me seems fully enough.

However, if there is a user requirement to show the historic code abbreviation then we should add it as a parameter in the enum (which is very easy to create, once someone gives me the full list, e.g. for the 1867 code I have no idea what the abbrev is).
To misuse the enum name for this to me does not seem to be the correct way and is against the general CDM philosophy use enum names neither as names nor as labels.

The Taxeditor is not the only UI we have. There is the UI where I took the screenshot from, therefore I don't quite understand your point.

What if this information is to be shown the Data Portal, would you just write "Cambridge 1935" without stating which code this is about? This is for sure not sufficient.

To misuse the enum name for this to me does not seem to be the correct way and is against the general CDM philosophy use enum names neither as names nor as labels.

I don't understand why you repeat this point, this is already discussed to an end. I made a specific suggestion how this can be solved? Do you need more details on this?

You mean the "Suggestion" above?

I do not understand why this needs to be a method for NomenclaturalCode.

Why not simply NomenclaturalCodeEditon.getLabel() . This is what I meant with "if there is a user requirement to show the historic code abbreviation then we should add it as a parameter". I implemented it this way now.

But as I mentioned above I need a full list of all correct abbreviations for all codes. As long as this list does not exist the abbreviations may not be correct.

Solution accepted. Ticket can be closed.