It would be great if we could define an language
AppText as a field type, this would solve
Dynamic Dropdown and many other issues around multi-lingual data.
Currently for dropdown or any type of content that is static in my database the only work around I have found is to create a field for every language I want to use.
Currently this is how I implement
I am open to hear about other ideas or work arounds.
was this ever resolved or is it still a pending feature request?
The OP seemed not to realize that they already have all the tools they need to solve this problem exactly in the same way that Bubble’s “App Text” feature does this.
What to do:
- Create a data type for App Languages. It has at least 1 field for Name. (The name of the language in the OP’s native tongue.) But it could have many – like Name Native (the name of the language IN that language - Like a Language representing Spanish would have Name: Spanish and Name Native: Espanol, right? It could also have a Flag (an image representing a Country or whatever… It could also have an ISO Language Code field, etc. (Of course these can always to added/extended later.)
Now make a few of those in the database, right?
Create a type Translation. A Translation has at least 2 fields: Translated Text (a text) and Language (type Language).
Create a type App Text. An App Text has at least 2 fields: An Original Text (for the default language - what we display if there is no selected Language preference for the app) of type text, and Translations, of type Translation and make that a List.
Now you build an App Text by creating an App Text with an Original Text field. Then as you translate the app you push a Translation onto the App Text’s Translations.
(The astute Bubble user will realize that such an interface is very simple to build with a nested repeating group structure. And also that one could expose that interface to trusted users in order to crowdsource translations for one’s app.)
So far, there is one feature I’d really appreciate: fetching all AppTexts so you can use them inside of a Repeating Group for example.
To describe my need for it, I’m using some of my AppTexts with “variables” (they’re my reserved keywords defined in a certain way) which I’m replacing dynamically depending on the context.
For example, let’s say I have this text: “The product !productname! is sold out”. The product name might be stored in my database, and I’m going to replace !productname! with my database entry using “find & replace” feature.
Now that means when my users are going to create a product, they can’t put “!productname!” (a name of my variable) in an input (even though it would almost never happen if not on purpose) to avoid replacing that string… That’s why if I could fetch all AppTexts I could easily check all my “variables” and prevent that from happening.
This has helped me many years later solve my problem XD.