Merged at https://github.com/openmrs/openmrs-module-webservices.rest/commit/0933bb614359c4a9b6fb2a8dc70ac81db4733bbf

Agreed

Fair enough. This strikes me as an important limitation of the concept name concept, since it seems like it should be possible to mark names for custom use-cases like this without changing the preferred name per se.

Answering a question from on the PR here:

Could you say more about the use-case here? I’m actually kind of uncertain about how good of an idea it is to add complexity to how concept display names are determined. But maybe this is a feature you’ve already been leveraging?

So this is an existing pattern we developed during the developing of O3 to support localizing metadata using messages.properties. You can see the support in the UI Framework here:

And it has been added to REST Web Services here as well, but never applied to concepts:

It’s true that initially this functionality was designed to originally to localize metadata (like EncounterType, Locations) that didn’t inherently provide localization in the data model, which of course of Concept provides extensive support for. But, it’s problematic in terms of tweaking display values. For example, this specific use case:

• We have a Program State called “Postpartum” and within the O2 Program Widget UI the request is to display “Delivered” instead of “Postpartum”. But “Postpartum” is still the “best”name, and we don’t want to/can’t change the preferred name on a CIEL concept just to satisfy this use case…

PR:

https://github.com/openmrs/openmrs-module-webservices.rest/pull/633