Thanks for the response. That certainly works for read-only channels, but I’m not sure about writable channels. I assume the i18n translation only works one-way.
I can see 2 options:
Option 1. Expose 2 channels, a read-only string-type one called “Gender” which uses the options and i18n files to show a textual representation and a writable number channel called “Gender Id”, which shows the gender as a code and can be updated by sending a DecimalType command.
Option 2. Expose only one string-type channel called “Gender” which uses the options and i18n files to show a textual representation when displayed, but the handler expects a StringCommand with a code in the payload (i.e. “1”) to update the thing’s gender.
IMHO the first option looks cleaner, but requires 2 channels for basically the same information. What do you think? Is there a recommended design pattern?