To translate a Bubble application, move recurring interface strings into App Texts, provide reviewed translations for the supported languages, decide how the app chooses a visitor’s language, and test the real workflows in each language. This Bubble multilingual app guide explains the Languages settings, user language fields, URL language parameters, translation CSV files, core error messages, right-to-left layout and the separate problem of translating database content. It is intended for people building usable products, not merely multilingual screenshots.
Bubble documents App Texts as static strings suitable for buttons, headings, hints, menus and system messages, not a substitute for the app database. They can be referenced by expressions and exported to CSV for collaboration with translators. That CSV must keep its identifiers and columns intact: an import can overwrite existing translations, including values associated with blank cells. Bubble also distinguishes web-language preferences from native mobile device-language handling. Those distinctions determine whether a translated label actually appears when a user needs it.
Start by inventorying each interface string and the dynamic records displayed beside it. Create a small supported-language set, translate the complete sign-in-to-task journey, protect text identifiers during bulk editing, and test missing-language and error paths. Once the first journey works, extend to data records, emails, formatting, accessibility and release management. The objective is the same throughout: a reader should understand what an action means, what happened, and what to do next.
Quick answer: the Bubble multilingual app checklist
- Inventory fixed App Texts, plugins and dynamic records
- Define supported languages and the primary fallback
- Configure the user preference field and test lang parameters
- Translate core messages and meaningful action labels
- Export a safe CSV copy and protect identifiers
- Check database localization separately from UI text
- Test web and native mobile language behaviours separately
- Review RTL, accessibility, dates, privacy and the deployed release
Definition lock: translation, App Texts and dynamic data
App Texts are static, language-specific user-interface strings referenced through Bubble expressions. A configured user language is a preference stored in an approved User field. A lang URL parameter is an instruction carried by a web address. The application primary language is a fallback setting. Dynamic content consists of records such as listings, courses or product descriptions whose translations need separate modelling. A locale refers to language and regional conventions; a market may have different business rules.
Complete tutorial: translating an application without changing its meaning
1. Define the boundaries of Bubble localization
Bubble localization has several layers. App Texts handle many fixed interface messages, while the database, option sets, workflows, plugins, uploaded documents and transactional messages may contain separate language-dependent information. Selecting French in Languages will not automatically turn every long user-generated article into French. Conversely, translating an article in the database does not fix an English error generated by the sign-in system. A strong design identifies the owner of each kind of text before editors begin translating it.
Practical test. Draw one journey through the product, such as registration followed by an appointment request. Mark each visible string with its origin: App Text, database record, plugin, external service or generated message. The map reveals the gaps that a simple scan of the editor’s language panel cannot find.
2. Choose supported languages based on product readiness
The number of translation rows is not a useful measure of whether a product supports an audience. Start with the user groups who need the application and the tasks they must complete. A service may offer a French interface but only English-speaking staff support; that limitation should be explained truthfully. Regional differences in date styles, address forms and payment rules need separate consideration. Prioritize one additional language and build a complete path before adding several partially translated options.
Practical test. Write a short audience profile with language, regional conventions, primary task, support channel and legal or commercial limitations. Include a native-language reviewer who can recognize when a technically accurate word creates the wrong expectation. Confirm there is a realistic way to maintain that language after launch.
3. Give the interface a stable primary language
Bubble’s Settings > Languages includes the application primary language. This is a fallback for users whose language preference is absent or invalid and influences language-sensitive elements such as some calendar or date displays. Decide that primary language deliberately rather than accepting a default and forgetting about it. Changing a fallback can change how users experience forms and errors even when the layout remains visually identical. A clearly chosen primary language is part of the product specification, not just a setting.
Practical test. Test a user with no saved language value, one with a supported value and one with an invalid value. Record the language shown by the main heading, the error text and any locale-sensitive widget. Use the observed behaviour to document the supported experience.
4. Understand App Texts as named interface strings
An App Text has an identifier and language-specific wording. It can be used wherever Bubble accepts a relevant dynamic text expression, including button labels, field hints and headings. The identifier gives the application a stable way to refer to the concept while the user sees the wording for their language. Treat identifiers as product contracts. A vague identifier such as Text17 becomes difficult to maintain, while an identifier describing a user action makes review and debugging easier.
Practical test. Create named App Texts for a small form: appointment_heading, preferred_date_label, continue_button and request_confirmation. Write the intended meaning of each in one sentence. A translator should know whether Continue advances to the next screen or submits an irreversible action.
5. Do not use App Texts as an article database
Bubble says App Texts are static data in the deployed application and are intended for short recurring strings rather than long articles or product descriptions. Treating them as a content-management system causes operational difficulties when editors need frequent updates, structured relationships or independent permissions. Dynamic content should normally have an appropriate data model with language-aware fields or related translation records. A published product description also needs current prices and stock state, which are not ordinary translation strings.
Practical test. Separate a fixed button label from a ten-paragraph help article. Use App Text for the former and design an editorial data model for the latter. Record whether users can edit the content, whether it changes weekly and whether it requires approval before publication.
6. Give each visible action one clear meaning
A multilingual product should preserve the consequence of an action, not just its button length. “Save draft”, “Confirm booking”, “Request quote” and “Pay” are not synonyms. Translating a button to fit a narrow space can erase a warning or change a promise. Work from the actual workflow action and write target-language wording that describes what follows. Then inspect the next screen and message to confirm that its language and substance agree with the button.
Practical test. Select five important buttons and document what happens when each is clicked, what is saved, and whether the action is reversible. Give that behaviour to the translator. Ask a reviewer to predict the outcome from the localized label alone.
7. Include Bubble core messages in your inventory
The Languages panel contains Bubble-provided core messages as well as strings created for the app. Some of those messages explain missing accounts, invalid inputs or connection problems. They appear at exactly the moment when users are already confused, so their clarity matters. A translated interface with English-only error messages can feel unreliable even when its happy path is polished. The message must state what happened and, where possible, what a user can do about it.
Practical test. Trigger a failed sign-in, missing input and network-related state in a safe test environment. Record the actual text and check whether its translation matches the product’s tone. Do not change the meaning of a security-related error merely to make it sound friendlier.
8. Remember that plugins may add their own strings
A plugin can introduce labels, notices and validation messages that do not belong to the main page design. Bubble’s language settings can expose strings associated with plugins, but support depends on the component. A user may encounter a third-party upload dialog, calendar or payment interface after navigating through a perfectly translated application. Inventory those surfaces separately and check the current plugin documentation before assuming every string is editable through Bubble.
Practical test. Test the whole feature rather than just the surrounding page. Open the upload control, cancel it, enter invalid information and complete a successful action. Mark any untranslated third-party message and decide whether the component is still suitable for the target audience.
9. Choose reliable language codes
Bubble’s translations use language identifiers; documentation describes IETF-style language tagging and provides examples such as fr_fr and ru_ru in the web app settings. The actual dropdown values are more important than guessing the code from a flag. An unrecognized value can trigger fallback behaviour. Regional distinctions matter when a phrase, date style or service policy differs between variants of the same language.
Practical test. Copy language codes from the live Bubble settings rather than typing codes from memory. Test them with the user field and the URL parameter, then record the resulting current language. Keep the same code convention in translation files and application data.
10. Understand the web app language selection rules
Bubble’s App Text documentation describes a language-selection sequence involving a lang query parameter, the current user’s configured language field, and the application primary language. The precise behaviour should be tested in the running application, especially when both the URL and saved preference are present. A visitor may intentionally switch language through a shared link while logged in with a different preference. The product needs a predictable rule and a visible method to recover from an unwanted language.
Practical test. Create a test matrix with URL language present or absent, saved language present or absent, and supported or invalid codes. Visit the same screen for every case. Record which language wins in the actual deployed app instead of explaining the product from assumptions about browser settings.
11. Set a user language field deliberately
Bubble does not assume that a User record already contains the product’s desired language preference field. Its documentation describes configuring a text or compatible option-set field and choosing that field in Languages settings. A valid saved preference is convenient for a recurring user, but it needs a clear way to be changed. Never use a country field as a direct substitute for language; a person living in one country may prefer another language.
Practical test. Add a language preference to a test account, save it, refresh the app and inspect the interface. Then change the preference and verify that the new value persists appropriately. Test a second account to ensure one user’s setting does not leak into another user’s session.
12. Use the URL language parameter with care
A lang query parameter can allow a link to request a language, such as a Russian version opened from an invitation. But app-generated links also carry other information, and an incorrect redirect or parameter rewrite can lose the target workflow. Language parameters should be treated as navigation instructions, not proof that every piece of dynamic data has been translated. Shareable links need to be tested with and without an authenticated user session.
Practical test. Take a deep link to a support page, add a valid language parameter and open it in a clean browser. Confirm that the requested screen remains the destination, the language is honored as expected and subsequent navigation does not accidentally discard context.
13. Create a visible language preference control
A good interface lets users choose a language without first reading complex instructions in the wrong language. Place the control somewhere discoverable and label choices with recognizable language names. A change might need a refresh for the latest strings depending on the current configuration, so the interface should communicate what happens. Do not surprise users by changing unrelated profile attributes or resetting their task when they choose a language.
Practical test. Ask a new user to switch from English to German during a form and then return to English. Check whether entered values remain safe, whether errors are cleared appropriately and whether the current choice is visible. Usability matters more than a clever animation.
14. Translate CSV files as structured data
Bubble supports exporting App Text translations to CSV and importing them again. The file contains identifiers and language columns; the exact structure from the current export is the specification. Do not rename fields, reorder identifiers casually or strip columns to make the file look cleaner. A translator may work in a spreadsheet, but the final file must preserve the structure and encoding expected by Bubble. This is a data-handling operation, not just a text-editing exercise.
Practical test. Export a sample file before translating anything. Save an untouched reference copy and create a working copy. Check the header row, identifiers, language codes, quoted commas and special characters after import into a spreadsheet. Work on the copy only.
15. Avoid destructive blank-cell imports
Bubble warns that importing a translation CSV can overwrite strings even when a cell is blank. A translator who deletes an unfamiliar entry rather than translating it might therefore erase a working value. Protect the non-language columns and define what blank means before distributing the file. When a language is intentionally incomplete, it is better to manage that state explicitly than to hope the import tool will preserve everything by accident.
Practical test. Before import, compare the working file against the untouched export. Flag removed rows, changed identifiers and unexpected blanks. Import into a safe test version where possible and inspect representative strings in the editor. Never treat a successful upload message as proof that the translations are correct.
16. Use a bilingual review process for bulk translations
Machine translation can accelerate an initial draft, but an App Text file is full of isolated fragments. A term like “Charge” might refer to a payment, an electrical quantity or a legal accusation. Without product context, a fluent translation can still be wrong. Give translators screenshots, workflow notes, glossary terms and examples of what each message does. Review critical actions with a native-language product user before publishing.
Practical test. Take a handful of ambiguous entries such as Save, Apply, Cancel and Failed. Record their meaning in context, the screen where they appear and the consequence of clicking. Ask the reviewer to rewrite them naturally, then test the actual screen rather than judging the CSV alone.
17. Separate interface strings from database records
A product catalogue, course library or user-generated marketplace needs more than App Texts. Consider a data model in which each record has a stable identity and related translation entries. Product identifiers, stock, prices and access permissions should not be duplicated merely to display another language. Otherwise content editing can accidentally create divergent business records. Decide what is shared, what is translated and what legitimately varies by market.
Practical test. Model a course with one course identifier, an approved price and language-specific title and description fields or linked records. Open the same course in two languages and confirm that the identity and payment conditions remain consistent. A translation should not create a second unrelated course.
18. Keep locale and market apart
Language controls how a message is communicated. Locale influences conventions, and market governs commercial or legal facts. A French interface may serve users in France, Canada or elsewhere, but those users may need different tax treatment or service eligibility. Bubble language settings cannot decide those business rules. Store operational facts in data and evaluate conditions deliberately rather than embedding assumptions into translated string values.
Practical test. For a hypothetical paid workshop, list the language, currency, available countries, cancellation policy and date format. Identify which values change because of user preference and which come from the purchased product or approved market policy. Test that switching language alone does not silently change the price.
19. Handle dynamic parameters carefully
Applications often build sentences from data: “Your order {number} arrives on {date}.” The order identifier must remain exact, while word order may change across languages. Concatenating English sentence fragments creates unnatural or ungrammatical results elsewhere. Prefer complete contextual messages with clearly identified variable placeholders and, where supported, language-aware formatting. Dates should be formatted for the intended locale without modifying their underlying timestamps.
Practical test. Write a confirmation with a name, date and status. Check it in two languages using the same test record. Verify that a translated template never swaps a reference number for a date or changes the factual status from requested to confirmed.
20. Test date, time and number formatting
Bubble’s language settings can affect certain language-sensitive elements. A date picker may show a different format or calendar terminology, but the application still needs to store dates consistently and distinguish time zones. A user scheduling a call from another country should know whether the time is local to them or local to the service provider. Translation does not solve ambiguous scheduling rules; it makes those rules more important.
Practical test. Select a future appointment near a daylight-saving transition and view it from two locale settings. Confirm the selected instant and displayed time zone. Test decimal separators and currency symbols independently when money is involved. Do not round or convert amounts simply to match a preferred display.
21. Plan Arabic and other RTL interfaces explicitly
Bubble documents a known issue in which text direction may revert during certain operations in right-to-left content. That warning means RTL should not be treated as automatically solved by supplying Arabic strings. Layout direction, punctuation, mixed digits, phone numbers and cursor behaviour need visual and functional testing. A translated word that looks right in a spreadsheet may appear in the wrong order inside an input or button.
Practical test. Build a small RTL test with a title, multiline explanation, form input, validation error and confirmation screen. Test typing and editing text, not only passive viewing. Include mixed-direction information such as an email address and booking reference. Document any component that cannot be made reliable.
22. Translate accessibility text and error recovery
Screen readers, keyboard users and people who rely on clear error messages need a coherent language experience. Accessible labels, link descriptions, help text and focus behaviour should be included in the text inventory. An icon-only button can be ambiguous when its tooltip or accessibility label remains in English. Verify what the rendered application exposes, not only what the Bubble editor displays.
Practical test. Navigate the core task using a keyboard and, if possible, a screen reader configured for the destination language. Trigger a form error and confirm that its meaning and corrective instruction are accessible. Do not use color alone to communicate success or failure.
23. Handle privacy and security consistently
App Texts are not a safe place for passwords, API tokens or confidential information. Bubble’s documentation explicitly warns against storing sensitive data in these static strings because they can be delivered with the app. Translators should not receive production user records merely to understand the interface. Provide invented examples or redacted screenshots. Security and privacy messages deserve careful wording because false reassurance could lead users to misunderstand what is stored or shared.
Practical test. Make a translator context pack using placeholder account details and fictional orders. Verify that exported language files contain only approved interface wording, not customer information. If a data policy changes, have the responsible owner approve the meaning before translators adapt the wording.
24. Treat mobile app language behaviour separately
Bubble documents different language selection behaviour for native mobile apps: supported device-language preferences and configured dialect fallbacks may determine which App Text translations appear. Its documentation also distinguishes translations that can be updated over the air from certain system-level prompts that require a new native build. Do not assume web URL-language parameters and native device-language settings are interchangeable.
Practical test. Test the application on a device whose primary language is supported, one whose base language needs a regional fallback and one with an unsupported language. Include a system permission prompt in the checklist. Record whether a content update or a new build is required for each kind of string.
25. Verify responsive layout under text expansion
Translations vary in length. A button that fits in English may become unreadable in German, while a compact card may wrap differently in French. Avoid solving all such issues by shrinking text until nobody can read it. Consider flexible widths, wrapping, line height and the action hierarchy. Component-level visual review matters because many multilingual defects are introduced by layout assumptions rather than incorrect translations.
Practical test. Open the longest relevant labels and error messages on narrow phones, tablets and desktops. Check the normal, loading, error and disabled states. Ask a reviewer whether shortened words still convey the intended action. A button should remain understandable without the surrounding English context.
26. Coordinate release and redeployment
Bubble’s documentation describes App Texts as static data associated with the app’s deployed version. A translator changing a string in the editor does not automatically mean that every live user has received that revision. Build a release step that confirms the relevant version was deployed, the language appears correctly and saved user preferences still work. For native mobile, check whether a change requires a binary rebuild.
Practical test. Create a release note stating which languages and strings changed, which workflows were tested, and which deployed version users can access. Open the live URL in a clean session after release. Do not sign off solely from a preview in the builder.
27. Maintain a glossary with examples, not only words
Short App Text strings are context-sensitive. A preferred term list should explain what each concept means in the product and how it differs from nearby terms. “Application” might mean a software app or a submitted request. “Available” might mean stock, scheduling or permissions. Give translators examples of complete sentences and approved alternatives; otherwise a termbase can encourage rigid, unnatural language.
Practical test. Review ten recurring user actions and their translations together. Confirm that the vocabulary remains consistent from the menu through the form and into the confirmation email. Where grammar requires different forms, record the acceptable variation rather than enforcing one phrase mechanically.
28. Create a sustainable localization change process
Whenever a new feature introduces buttons, plugin strings, emails or database descriptions, the language inventory must grow. Without a maintenance workflow, the product gradually returns to its source language one feature at a time. Assign ownership for newly created App Text IDs, translation review, CSV changes, staged testing and final release. High-risk changes to policies and payment actions should receive review sooner than ordinary decorative wording.
Practical test. Add a translation requirement to the feature acceptance checklist: new text has an identifier or data-field owner, supported-language wording, a tested fallback and a documented release path. Review the entire product periodically for fragments that users encounter only during uncommon errors.
Nine worked product scenarios
A bilingual appointment app
An English-German appointment application contains a date picker, service names and a confirmation. The developer translates button labels through App Texts but initially forgets that a stored service description is dynamic data. German users see a German confirmation screen containing an English service title. The fix requires a translation field or related record rather than another App Text. The team also checks the time zone, since a date that looks familiar can still represent the wrong appointment. The result should be one booking identity displayed understandably in either language.
A product with a dangerous empty CSV cell
A translator exports Spanish App Texts, edits a spreadsheet, then deletes an unfamiliar row and leaves several cells blank. Bubble’s import behaviour can overwrite corresponding values. A safe team preserves identifiers, validates blanks and reviews differences before importing. Once imported into a test version, the team checks a sign-in failure and a password reset. These are not glamorous screens, but they reveal whether the bulk translation operation damaged critical text. The source export remains available as a recovery reference.
A marketplace with multiple languages
A second-hand goods marketplace has French and English interface options. Listing descriptions come from sellers, not from the App Text table. The product should not imply that every listing is professionally translated merely because menus are bilingual. It can label the language of each listing and offer a separate translation workflow where appropriate, while keeping price, seller identity and item ID attached to the same record. Moderation and safety notices need verified wording in both interface languages.
A web link that overrides a saved preference
A French-speaking member saves French in their profile. A colleague shares a support link containing an English language parameter. Depending on the app’s tested language precedence, that link may temporarily display English. The interface should make the active language obvious and let the member restore French without losing the support article. This scenario is why a precedence table and a direct-link test matter more than simply storing a User.Language field.
An Arabic onboarding flow
A nonprofit app localizes its onboarding into Arabic. Labels are translated, but an RTL form exhibits awkward cursor direction around a phone number and email address. The team tests real entry, error correction and mobile rendering rather than accepting the translated screenshot. Where an individual component behaves unpredictably, they investigate a more suitable input pattern or record the limitation. They do not conceal the problem under a visual overlay that prevents keyboard access.
A support team with one response language
A service can present a Spanish interface without employing Spanish-speaking staff. The contact screen must not say that support is provided in Spanish unless that is true. The translated enquiry form should state the actual response-language policy, and internal staff should see enough information to handle the request. The translation professional ensures the statement is understandable; the operations team approves what the company can deliver.
A mobile app with a regional dialect fallback
An app supports French for Canada and Belgium. A user device reports only a base French language code. Bubble’s documented native mobile fallback dialect configuration should be tested to confirm which variant appears. The team also checks system permission wording, which may require a new native build. This is not merely a preference-screen translation problem; it is a release-management issue that spans device settings, app configuration and installed binaries.
A checkout error message
An app shows “Payment failed” in one language and a translated alternative that implies money was charged. The translation changes the customer’s understanding of the outcome, despite grammatical correctness. The owner checks the payment provider’s actual result, then the translator writes a faithful message with a safe next step. Reviewers test a declined payment and a successful payment separately, never assuming all errors mean the same thing.
A course app with long editorial content
An education app contains hundreds of detailed lessons. Placing them in App Texts would make ordinary updates cumbersome and blur the line between interface copy and editorial resources. A cleaner data model keeps lesson identities stable while attaching approved translations, status and reviewer information to each lesson. Buttons such as Start lesson and Continue remain App Texts. This division allows the product team to ship a new interface label without rewriting the course catalogue.
Four-week implementation plan
Week 1 — design the language contract: Choose supported languages, identify all UI and dynamic-data text, set the primary language and create a clear vocabulary for actions and error outcomes. Test how URL and saved preference choices interact before translating dozens of strings.
Week 2 — translate safely: Move repeated fixed wording into named App Texts, include core and plugin messages, export the CSV, attach contextual screenshots and obtain bilingual review. Maintain the exported structure exactly and compare the edited file before import. Model any long editorial records outside App Texts.
Week 3 — test user states: Run language-preference combinations and visit the app as a guest, a signed-in member and a user facing an error. Check mobile layout, RTL where relevant, date and number formatting, missing records and the consequences of every important action. Correct the defect at its source.
Week 4 — publish and maintain: Deploy the correct version, confirm the live language behaviour on clean sessions, test native builds separately if applicable and assign a reviewer for future changes. Require new features to identify their translation strings, dynamic-language data and fallback behaviour before release.
Frequently asked questions
What are Bubble App Texts?
They are named static text strings used for interface labels and messages, with language-specific values that can be referenced from dynamic expressions.
Will App Texts translate my database automatically?
No. Dynamic records and user-generated material require their own translation and data-model strategy.
Can I let a translator work without editor access?
Yes. Bubble documents a CSV export/import workflow for language strings. Preserve the identifiers and column structure and use a safe review process.
Are blank CSV cells harmless?
No. Bubble warns that importing can overwrite strings even when cells are left blank. Compare the edited file with the original export before import.
Which setting chooses the current language on the web?
Bubble supports URL language parameters, configured user language fields and an application primary language. Test the documented precedence in your running app, especially where preferences conflict.
What language code should I use?
Use the recognized value from the current Bubble Languages settings. Do not assume that a flag or region name maps to the required code.
Is right-to-left text fully automatic?
No. Bubble documents an RTL issue in some editing or display operations. Test real RTL workflows and mixed-direction inputs.
Does native Bubble mobile use the same preference path as a web app?
Not necessarily. Current documentation describes device-language selection and configured dialect fallback for native mobile.
Should translators receive live customer information?
No. Use fictional test records and redacted context. App Texts should never be used to store confidential information.
When is the translation ready to release?
When the full task, including validation and failure states, reads correctly; the deployed version is verified; dynamic records are addressed; and users have a predictable language choice.
Final release checklist
- Core, custom and plugin strings reviewed
- Language codes and precedence tested
- CSV IDs and columns preserved and blank cells audited
- User preference and URL language controls behave predictably
- Dynamic records have a separate approved translation strategy
- Error, confirmation, privacy and payment wording is faithful
- Dates, money and regional rules remain factually correct
- RTL, keyboard, screen-reader and mobile states inspected
- Required deployment or native build completed
- A change owner and regression checklist are in place
Official sources and continuing study
Bubble Documentation — App Texts (Translations) explains how language strings, CSV, preferences and mobile language behaviour work. Bubble Documentation — Languages Settings describes core messages and RTL considerations. Bubble Documentation — URL Parameters explains parameter structure.
For translation principles that remain useful beyond one app builder, see the Master Art of Translation complete system and the Translate Like a Pro series index.