App texts (translations)
This section covers how to translate your app into multiple languages
Last updated
This section covers how to translate your app into multiple languages
Last updated
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.
The editor will show the text App text ([name]) and the app will show the string you have saved in the app text editor in the currently active language.
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 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.
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.
Click the Export button and download the CSV file that Bubble generates
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
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.
Bubble determines the app's current language based on the following hierarchy:
The "lang" parameter in the URL if it is set
The current user's language if the field exists and is it's value is valid
The application primary language
English
Application texts are set up for multiple languages, and uses the 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.
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.
The application language can also be set in the URL, by using the lang query string parameter. This means adding lang=code to the URL, where code is the standardized language code, i.e. the one found in Settings > Language (most, but not all, of these codes have the format of two characters, underscore, two characters).
For instance, using Russian in your app would be done by hitting this URL https://myapp.com?lang=ru_ru.
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.
Known Issue: right-to-left (RTL)
When displaying text in a right-to-left (RTL) format and applying certain operations or changes, the text might switch back to a left-to-right display.
If you're prioritizing RTL support, we recommend previewing your pages in run-mode to ensure they display correctly.
If you can't see the changes you've made, please check the following:
Changes in app texts are visible as follows:
Development: after the page is refreshed
Live: after the app has been deployed and page has been refreshed
Check that you are viewing the app in the same language as the string you have changed
Check that the Saving indicator next to the edit menu is showing Saved to confirm that the change has been synced to the Bubble server. If not, please check your internet connection.
