Localization of enums

Scott_Nesbitt · 03-17-2023 08:57 AM

I am looking for a way to localize Enum and EnumLists (Yes, No, etc.)

I saw another post mentioning that it could be done with a special lookup, but the post did not have details (and I cannot find it now.) Could anybody provide more information or an example?

Thanks

Marc_Dillon

This?

https://www.googlecloudcommunity.com/gc/AppSheet-Q-A/DISPLAY-PARAMETER-FOR-ENUM-LIST-ITEM/m-p/533387

Scott_Nesbitt

That's the one, but I am having trouble implementing it. My Enums table looks like this:

(I actually would rather it look like my Language table, which is like this:)

I made the original column with the enums be a reference to this new table, but it is not honoring the selected language. Any idea what is wrong?

Thanks

Marc_Dillon

How do your users select the language? You set up the Virtual Column Label? What do you mean you'd rather it looked like your language table, in what way?

Scott_Nesbitt

I have a Change Language option in my hamburger menu:

I based it off the multi-lingual Covid-19 template.

The Lanugage screenshot I showed has different languages in rows and words/phrases in columns. From what I understand your idea is the reverse.

I did set up a virtual column like below, but it is not working:

Marc_Dillon

What is the full formula from your last screenshot?

The Lanugage screenshot I showed has different languages in rows and words/phrases in columns. From what I understand your idea is the reverse.

Indeed it is. You want the same option value to be recorded no matter which language the user has selected. That's why each enum option is its own row/record, and the enum column is a ref to those records, while displaying a dynamically changing label value per language. That language table structure is not applicable to this situation.

In fact, I'd say that structure is terrible for any situation. It's not scalable, for every new word/phrase/etc that you need to translate, you'd need a new column. That's bad. Is that in some official translation sample app?!

Scott_Nesbitt

Hmm, not sure I understand why you think it is not scalable. I am almost done with the (non-enum) localization and it is working fine. And yes, it comes from the officlal AppSheet Covid-19 template.

Here is an example formula:

LOOKUP(usersettings(Language), Language, Language, "Created By")

Marc_Dillon

not sure I understand why you think it is not scalable

As I said: "for every new word/phrase/etc that you need to translate, you'd need a new column"

That means you have to go into the editor and make a change (namely: regenerate). Whereas with my suggested setup, you simply add a new data record.

And yes, it comes from the officlal AppSheet Covid-19 template.

That makes me cringe...

LOOKUP(usersettings(Language), Language, Language, "Created By")

That's why it's not working, this expression make no sense at all for the setup that I suggested. The new virtual column, which you'll set as the label, should contain the language-translated display value. You want an expression like this:

SWITCH( usersettings(Language) , "English" , [english] , "French" , [French] , ...)

Marc_Dillon

Well, I thought about it some more. That Language table isn't quite that bad, for that specific situation. Assuming the number of elements to translate is relatively static, i.e. mirroring the options in the in-editor Localize settings, then the most scalable direction would be adding languages, which is does allow.

Whereas my suggestion is scalable in the other direction, easily allowing more translatable items to be added, but assuming the number of languages is static. If the number of languages needs to be scalable as well, I'd stick with the basics of my suggestion (1 record per enum option), but then add another table to hold the translations, and have the VC Label column select from that child table.

The main point is that for Enum option translations, the requirement is added that all different translations still need to be the same selected option. Or at least they need to be if you intend to base any other functionality off of those values in a scalable way. Your language table cannot meet that requirement

Scott_Nesbitt

Thanks for the response. I am fine with the Enum table having a different orientation, I just am having a bit of trouble getting the formula to work in the VC. Could you please provide an example?

Marc_Dillon

provide an example?

I thought I already did:

@Marc_Dillon wrote:

SWITCH( usersettings(Language) , "English" , [english] , "French" , [French] , ...)

Scott_Nesbitt

Well, for this table:

I get this error:

So I am doing something wrong.

Marc_Dillon

You forgot to include the default result argument to SWITCH.

Scott_Nesbitt

Ah, of course. Sorry, don't use SWITCH() much in AppSheet.

However, while the app runs it does not change the buttons when I change the language. For this Enums table:

When I select French the app still shows Yes / No:

Marc_Dillon

Your first screenshot doesn't even show the new VC, much less having it marked as the Label.

I feel like you need to just go back and read my original suggestion a lot more thoroughly.

Scott_Nesbitt

That was a screenshot of the Enums table, not of the table that has the virtual column. I indeed have read the suggestion in the other post multiple times, but it is not very clear.

I am a bit shocked that for something so basic (localization) Google does not have a full working example / template. (And the partial template I did see was not best practice.)

Marc_Dillon

Step 3: add a new virtual column to the new table

The first step is to create a new table. The subsequent steps reference "the new table". How is that not clear? Your VC sounds like it's on the wrong table.