Ability to show localized values in the "Patient sex" field

[Maksym-Kozub]

Now, irrespective of the interface language, I see "M", which obviously stands for "Male". There is a problem (although a relatively minor one), in that unlike Patient Name, where it is sufficient for users to know the Latin script to recognize the name, Patient sex has different words in different languages. For example, in my language, Ukrainian, there is "Ч" ("чоловік") for "male", "Ж" ("жінка") for "female", and "І" ("інший") for "other". Does Orthanc store that sex value in the database simply as M/F/O (in which case we can hardly do anything), or maybe there are some abstract values like 1/2/3? In that case, if Orthanc just prints out "M" for 1 "F" for 2, and "O" for 3, then, as far as I understand, we can make it a localizable string.
It may become a bigger issue if and when some new language is added and it turns out that in that new language the word for "female" starts with "m", or the word for "male" starts with "f" :).
I know that under the standard, the values in DICOM are what they are, i.e. M/F/O, but I would consider arranging more "human-friendly" strings to be printed out. In that way e.g. a Mongolian doctor who does not speak English that much would see in Mongolian localization the first letter for the Mongolian word for "male" instead of M.
By the way, many thanks to @sscotti for reminding me now about the fact that the standard has that third option, O.

[amazy]

We have no short term plans to translate tag values right now but will keep this issue open as a reminder.

Note that, in real life, there are other values too like U, 0, 0000 -> everything this not M or F shall then be considered as O.

[Maksym-Kozub]

We have no short term plans to translate tag values right now but will keep this issue open as a reminder.

Thank you, Alain.

Note that, in real life, there are other values too like U, 0, 0000 -> everything this not M or F shall then be considered as O.

Yes, I know that there are various options, inconsistencies between DICOM and HL7, etc. By the way, I have found a discussion that may be of interest to you in this context: https://groups.google.com/g/comp.protocols.dicom/c/DZtLbcnC434. Among others, David Clunie, who is, as far as I remember, one of the authors of DICOM standard, shared some ideas there.