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.
Create a new option set to store all the translations. We can call it Translations for example.
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.
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.
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.
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!
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.
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.
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.
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 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
@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.
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?
(I am on this topic these days)
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.
