Multi-language option set approach

[spaccesi]

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.
   

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.
   

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.

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.

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!

[viquarahmed07]

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

[cmarchan]

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?

https://manual.bubble.io/help-guides/customizing-an-application/language-and-app-communications

[spaccesi]

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.

[cmarchan]

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!

[spaccesi]

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.

[serge]

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

[sainbayar100]

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.

[spaccesi]

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.

[boston85719]

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.

[abdoullahhedev]

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

Bubble Option Sets Helper

[spaccesi]

Thanks for sharing!

[alerojasch]

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.

[notjrag]

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”.

[tim27]

I like this approach and am trialling it myself 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

[erlendne]

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.

-Erlend

[rio]

@erlendne Thanks for the simplest solution!