App texts (translations)
This section covers how to translate your app into multiple languages
App texts, short for Application texts and messages is a sort of database for text strings that you can use around your app. It can be used for a single language, but Bubble also lets you translate all the strings into different languages to offer your users a multilingual app.
Application texts are a part of Bubble's static data features. This means that they are not dynamic, like the database, and that the app needs to be redeployed every time something changes. As such, they are not meant to store long strings of text like articles and product descriptions, but shorter content like headers, menu options and button labels.
Application texts become part of your application's codebase and is downloaded to every user on page load. You should never use these strings to store sensitive information.
Application texts can be used in any expression, meaning that it can be assigned to any element property that accepts dynamic texts: this includes text elements, labels on buttons and checkboxes, text input fields, tooltips an many other places.
Application texts can be used in any dynamic expression. In the screenshot above we're using an app text called My input as the placeholder for a text input element.
This also means you can use them in workflows, element conditions and any other place where you can insert a dynamic expression. In the example above, we have selected App text as the data source, and My input as the operator: this is the ID of the particular string we want to show, which means it needs to be created first.
To access the application text editor, go to Settings - Languages. Under General settings you will find your app's default language and the field on the user that determines the user's language preference (more on that below).
Under Application texts and messages you will find all the custom text strings that you have added (if any) as well as Bubble's core texts.
The left column is the ID of the text. In the example from earlier, the ID of the text was My input. We'll find this ID and
The strings ID is on the left side, and the string that will be displayed to your users is on the right. Click the image to enlarge.
The core texts are the text strings that Bubble includes by default. You can change their string, but they can't be deleted and their ID remains static. These strings cover different error/informational messages connected to Bubble's core functionality. These built-in texts are already translated into all the available languages.
Some elements and plugins also add text strings that become available at the bottom of the list. For example, the multi-file uploader plugin adds standard texts such as Cancel upload and Remove file.
Application texts are set up for multiple languages, and uses the IETF language tag language codes to identify each language and dialect.
The main language is the language that is used by Bubble to run your app when no language setting is set. This language will be used to define the messages that your application can send and show to users and change how location-sensitive elements behave.
For instance, it will impact how dates are formatted in the Date Input element and the Calendar element or the map element's captions.
Users in Bubble don't have a language setting field built in, but lets you set one up if you need it. The name of the field is not important, but the field must return a valid IETF language tag to work – in other words, the field must contain a text that matches one of the abbreviations in the dropdown
The language field on the user must return one of language codes in the language dropdown, such as fr_fr.
When you have set up the field, you assign that field to control the user's language setting with the dropdown Language field on the user type. Select the field you set up, and Bubble will automatically respond to the value in the field to display strings in the user's language.
If the field is empty, Bubble will default to the language set in the Application primary language dropdown.
To translate texts, select the language you want to translate into with the Currently editing messages and texts for dropdown. When you select a different language you will see the strings change. Strings that have not been translated into that language will show the text (no translation).
Bubble also lets you export all the language strings to a CSV file and then re-import the file after having made the needed adjustments to it. This way you can efficiently invite other users to translate the strings without giving them access to the Bubble editor.
- 1.Click the Export button and download the CSV file that Bubble generates
- 2.Make the needed adjustments to the file, but make sure that no text ID's are changed and that the columns remain exactly as they were when you downloaded the file
- 3.Click the Import button and select the finished file.
Importing a CSV file will overwrite all strings, even if the cell in the CSV file is left empty. If you want to keep a string as it was upon export, make sure it remains in the file.
If the user has selected a language and a string on the page has not been translated into that language, the text (no translation) will be displayed instead. Bubble's error console in the bottom right corner of the debugger will also flag a warning when you preview the page.
If you have set a field on the user to be a language field and that field is empty or returns an invalid language code, Bubble will default to the language set in the Application primary language dropdown.
The application strings you add become part of your applications JavaScript source code files. This means that they are downloaded to every user that opens up any of your pages.
For performance reasons, Bubble only downloads the text in the language that the user has selected – this is why changing the language on the user requires a page load so that the updated JavaScript file can be generated and downloaded.
Application strings are no more performance-taxing than placing the string directly on the element; if they are used in multiple places they are more lightweight, since they only need to be stored once. Even if you don't plan to translate your app it can be useful to maintain all your strings in one place.
Yes, Application texts support RTL languages such as Arabic, Hebrew and Urdu. Note that you may need to tweak your app design if you plan to switch between LTR and RTL languages, so we recommend testing your application in both languages.
Last modified 1mo ago