Multi-language option set approach

Hi, I ran into a problem during the internalization of our app. Basically, it is not natively possible in bubble to add dynamic text to text fields in the database. This is particularly annoying when you want to add multilanguage to your application because of the option sets.

I came up with this solution and I think it might be useful for other people. If you think there is a better solution or have any feedback please let me know in the comments.

First we need to make some changes to the option sets.

  1. Create a new option set to store all the translations. We can call it Translations for example.

  2. Add two fields to Translations, language_code and language_text, both plain text. In my case I am using the display as language_text and another option called Languages instead of plain text in language_code.
    Captura de pantalla 2022-08-22 a las 11.08.15

  3. Update the set of options you want to translate by adding a list of Translations. In this case, I will translate my Rols option set.
    Captura de pantalla 2022-08-22 a las 11.14.12

  4. Add as many translations as you want. You have to create it in the Translation option set, but also add it to the Translation List in the option set you are translating.

Captura de pantalla 2022-08-22 a las 11.13.56

Captura de pantalla 2022-08-22 a las 11.14.38

Now in the UI, we need to add the list of translations for the option that needs to be displayed and filtered by the current language. Note that in my case users can have multiple roles.

Captura de pantalla 2022-08-22 a las 11.31.21

You can change the language of the app in two ways, through the path, adding the “lang” variable or through a field in the database of each user. For me the path has more priority than the field in the db. But you can change the priority order in the filter without problems.

I hope this is helpful to someone!


Hi @spaccesi
Posted at right time :wink: (I am on this topic these days)
Thanks :+1:

1 Like

Hello @spaccesi welcome to the community and thanks for sharing!

Could you please elaborate on how this great approach differs from using Bubble’s AppText?

Of course @cmarchan, as I said in the introduction, you can’t just add AppText in any field within an option set (or database) that will cause inconvenience when faced with adding multi-language in your application.

Continuing with the Role example from earlier, you have this set of options that you can add to your users to identify the user’s role in your platform.

Let’s imagine now that you have to display users with their role. Using AppText and conditions you could get the same result but that solution is not scalable. For example, what if you want to add a new role on your platform? Then you have to manually add conditions throughout your application where that role appears. Depending on the application you are building, this could be in many places, which means more work for you and potentially more bugs for your users.

Don’t get me wrong, AppText is great, but at the moment it’s not the best for this particular case. I hope this help you.

Thank you for the comments. I am sure you have considered all options. In my apps a user can change the entire app everywhere with just one change in a language dropdown. Multiple languages as needed. I manage visibility and access through user roles. All text UI through AppText. Very performant as no client filtering is needed. Works great! :wink:

Sounds great @cmarchan! But first of all, client filtering is not a big issue here. The option sets are faster than normal database data requests and we are filtering only a few values. Secondly, remember that scalability is not only about performance. It is also about making your code easy to adapt to new requirements, maintainable and easy to understand by other people.

Pd. I think there are a lot of parallels here with the difference between using dictionaries or if/else statements.

1 Like

Best idea ever to translate an option set !
Thank-you @spaccesi

HI @spaccesi & @cmarchan , I was thinking to use App Text? method for all possible fields in the app, and also use the different language text display options as attributes in option sets and trigger separate workflows (1 for App Text changing the elements texts, and the other workflow is by pulling the selected language texts from the option sets by configuring the conditionals within the properties of concerned field). Does it make sense, and would it work? Or maybe I can tie both actions in 1 backend workflow?
I am having a trouble thoroughly understanding @spaccesi 's explanation. From what I understand is that you have to create a list of translated texts for each language for all text fields in general (not only option sets). Or are you referring to option sets only? Thanks for clarification - it is quite an important concern for me right now.

I only recommend the method explained in the post for translating option sets displayed in the UI. AppText works perfectly for static texts and you should use it as much as possible.
Adding different attributes in your sets for translations will work but personally I don’t recommend you to do it this way.
You need an option set (Translations) with two attributes (text and language_code) and a Translations list attribute on each option set you want to translate.

1 Like

I use app text for everything static. I use option set for anything else I normally use option sets for. I think ultimately Bubble needs to add ability to upload as CSV to option sets since they are pretty much the exact same thing as app text.

I can send a CSV file to translators for all app text, quickly and easily, but option sets either it’s me (not really, time is too valuable) or I hire and have somebody translate directly into option set (can’t preview app and test during this process) so translating option sets is more time consuming and annoying than app text.

there is a chrome extension that can do that but it’s a nice feature to have for sure


Thanks for sharing!

1 Like

I did something similar that includes that the user can save its preferred language (the languageCode), then I use a mirror code (ej. en ->en_us) to set the language for app_text?
Then the user can see data and labels in the same language no matter what language has the browser.

Im a little confused at the UI part. Can you share the settings if there are no roles for users? Although i do have a language setting for my users which is either “English” or “Japanese”.

I like this approach and am trialling it myself :+1: The only change I would recommend is adding an extra Attribute to the Translations table to allow English/developer’s language in the Display and the Translation to be stored separately.

When selecting the App Text (?) the programmer would need to understand the translation to pick the correct one. This assumes a knowledge of lots of foreign languages! By using the ‘local language’ in the display and a reference to the language code programmers do not need to understand the translation to select it. Example usage:

Display: Critical March - en_us, Translation: Critical March, Language Code: en_us
Display: Critical March - fr_fr, Translation: Marche critique, Language Code: fr_fr

1 Like

I figured out a way that worked pretty well for me. I set up the option set like this:

And then the dropdown menus like this:

For static text I just use the App.Text bubble functionality.



@erlendne Thanks for the simplest solution!

Thanks a lot for this! I spent a couple of hours trying several ways and your answer solved my problem in seconds!

@spaccesi this tutorial is working for me, and althoug I haven’t tried other approaches, this really looks like the "neatest"option for multiple languages. For folks that are still undecided - The main advantage is that once you set it up, if you add new language in the future, you ONLY need to update 2 option sets - no need to mess with conditions, etc.

THe only thing that is not working for me is the “:defaulting to en_gb” in the constraint - the UI somehow is not letting me to put brackets () or :defaulting to … . The workaround is that I have to force the app to assign a lang in the URL on page load - that will be triggered for new users/visitors.

1 Like

Hi there, I have just read your comment on how you set up your app so “a user can change the entire app everywhere with just one change in a language dropdown.”

I would like to achive the same thing in my app. Did you use an option set (displaying different language options) displayed in a drop down menu?

May you you please explain a bit more how you have achieved it?