Feature Request: Allow conditional/expression-based display text for individual Enum and EnumList values (localization) Tags: Localization, Enum, EnumList, Column Types, Feature R

AppSheet AppSheet Q&A
1

Display Name supports an App Formula, so field labels can be localized. Enum/EnumList Values cannot; each entry is a fixed string with no expression option, so dropdown options always show the same language to everyone. The only workaround is converting the column to a Ref pointing at an auxiliary lookup table, which is heavy overhead just for translated display text.

Requested behavior:

  1. Preferred: allow a per-value expression on Enum/EnumList Values, similar to Display Name.
  2. Alternative: officially document the Ref+lookup workaround as the recommended pattern.

Steps to Reproduce:

  1. Create a table with an Enum column, e.g. Values = [“Crop field”, “Vegetable garden”, “Courtyard house”].
  2. Set up a way to detect user language (e.g. a Language User Setting + USERSETTINGS("Language")).
  3. Confirm Display Name accepts an expression (e.g. =IF(USERSETTINGS("Language")="Turkish","Tür","Type")) — this works.
  4. Try to do the same for one Values entry (e.g. show “Crop field” as “Tarla” in Turkish) — no expression option exists for individual Values.
  5. As a workaround, convert the column to Ref, add a lookup table (Key, TR, EN columns) with a virtual Label column using LOOKUP()/USERSETTINGS(), and set Valid_If to the lookup table — confirm this does work, showing the platform supports the underlying need but doesn’t expose it for Enum/EnumList.

Impact:
Any multi-language app using Enum/EnumList for user-facing choices needs a manual Ref+lookup migration per column just to translate dropdown text; disproportionate overhead for a display-only need.

2

Everyone can have a different preferred option.

So your suggestion may be good for some colleagues and situations.

However in my opinion, the ref table is a better option. This so because most changes such as adding a new language or new value in an enum / enumlist can be handled at table record level rather than touching the expressions in the editor.

Also in general, the look up table can be common across multiple enum / enumlist columns where translation is required.

3

Yes that is an option. But in All AppSheet structure the display name can be created conditionally.

If you accept the enum as a content yes no need. But if you accept the enum as the structure it could be better.

Actually this would be an option. If you still want to use the ref table you still can.

4

Boolean type also, in a way, contains 0-1 two options enum value type. But it has condition/expression inside.

The enum should work similarly. But this time additional values should not be entered by the users. Because users can not enter the conditions by themselves.

5

I agree with @Suvrutt_Gurjar.