🌐
Multilingual apps
IntegrationsAdd multiple translations to the texts in your apps by setting up the multi-language feature! This way, the app texts will be displayed in the same language used by the device.There are two types of text content in an app.
- Static texts. These texts are set in the design tool (Figma or Adobe XD), and not connected to API data.
- Dynamic texts. These texts are defined in a backend tool, and fetched by the Bravo app via API request.
You can see below how to set up multiple languages for both text content types.
As explained above, the static text is defined in the design file, and not connected to API data. This means the text will always be the same. Some examples can be the title of an app page, the app sections, and so on.
Once you have successfully created an app by importing a design file, you can set up multiple languages for its static texts (defined in the design file) by navigating to
Integrations -> Multi-language. There, in Language settings, you'll be able to choose the app's original language: the language in which the design file texts are written. Then, you can add as many translated languages as you wish.
After specifying the original and translated languages, you can go to
Translations. Here, you'll need to insert the translations for all the static texts in the app, for all the translated languages indicated previously. As you can see below, each of the languages will have an associated file.
There are several ways to edit the language files:
- Upload a JSON file with the translations for a specific language. You can consult the format of the JSON by opening one of the existing files. If you see the red cross icon, that means the file for that language has been created, but it's missing the translated texts. You can also download the file and edit it on your computer.
- Edit the file inside the platform. To do that, click on the pencil icon on the corresponding language file, and edit the translations on the right column.
Once you have set all your translations, your app will be ready to show the texts in the language the phone device is set to.
It's a good practice to add information with the languages your app supports (i. e. the translations you have included), for instance in the app intro flow.
Having support for multiple languages for dynamic text requires a different setup. This support relies on the use of the built-in
device.lang variable. This variable will allow to send the language code of the device language via API request.Supporting multi-language on dynamic texts (i. e. texts retrieved from a backend tool) requires a specific setup in the backend, where a request containing a specific language code returns the texts in that same language. We'll show an example using Airtable below, but the setup required on the backend would depend on the specific tool.
The first requirement on the backend side is having the texts in different languages already stored in your database. For instance, you could add duplicated tables for each language, as shown below:
Here, the codes for the supported languages have been added to the end of the table name - as you can see, this app would support the English and Spanish languages. This is done to have a single API request target different tables with the corresponding translations, depending on the value of the device.lang variable (more on this later). This will allow us to bind the same data items to the app UI elements, which will actually contain different values depending on the device language.
Once you have all the supported translations for the app text content, it's time to create the necessary API requests on the Data Collections section.
We'll need to create a single API request for all the languages for a specific table type. In our example, we'll have a single list request (and detail request) for the Places and the Journal tables, which will target the corresponding language table depending on the device language (by setting the
device.lang variable in the URL).To match the naming we defined on Airtable for the language-specific tables, our GET requests will look like this:
https://api.airtable.com/v0/base_id/Places-${device.lang}/
https://api.airtable.com/v0/base_id/Journal-${device.lang}/
After setting up the request URL, you can test it by specifying a test value for the device.lang variable.
Once you have managed to send a test request, you can bind the data items to the app UI elements as usual. Remember that the same data item will have a different value on the app (i. e. the text in different languages), depending on the value of device.lang.
As you might have guessed, in case a device language is not defined on your backend, the request will throw an API error like 400 or 404. In this case, it might be useful to create error pages where you indicate which languages your app supports.