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