How do you make a Bravo Studio app multilingual when some text comes from a Figma or Adobe XD design and other text comes from an API? This guide explains Bravo Studio localization, static translation files, device language preferences, the device.lang variable for dynamic content, and realistic tests in Bravo Vision. It is for designers, app owners and translators building mobile experiences for people in different countries.
Bravo Studio’s published help separates static design text from API-driven text. Its multilingual integration describes choosing an original language, adding translated languages and editing or uploading language-specific JSON files. For dynamic responses, the device.lang variable can be supplied to an API designed to return the appropriate language. These are useful capabilities, but they do not automatically translate arbitrary backend data or guarantee that unsupported locales will work.
The practical question is whether a person can complete an entire journey in a language they understand. They may open an app, read a place description, sign in, submit a booking, receive an error and return the next morning. Every message must represent the same true data and action across locales. This chapter begins with the working boundaries, then moves into examples, failure cases and a test plan that can be applied to a real release.
The quick answer
Use Bravo’s documented multi-language integration for eligible plans and maintain reviewed translations for static design text. Treat API content as a separate localization problem: provide translated records in the backend and use a documented language variable when requesting them. Test an unsupported device language, delayed API calls, forms, permissions, longer strings and the actual mobile build. Do not assume native UI translations also translate app-store listings, notifications or backend emails.
What to check before launch
- Confirm the current Bravo plan exposes Integrations > Multi-language.
- Identify every static phrase inherited from the design file.
- Translate static text through supported language files; audit missing keys.
- Design a backend language strategy before using device.lang in requests.
- Provide a deliberate default for unsupported device languages.
- Keep data record IDs and authorization independent of language.
- Test navigation, errors, submission outcomes and stored preferences on devices.
- Run Bravo Vision preview and verify a release-equivalent native build.
A practical way to understand the system
A Bravo project joins a designed native interface to external data sources. Localization crosses that boundary. The native screen may show a translated heading while the API returns a source-language description, or a form may look translated while the server supplies an unfamiliar error. The objective is not to make those layers identical internally. It is to make their meaning agree for the person using the app.
1. Understand the two sources of visible language
Bravo’s documentation distinguishes static words specified in the design file from dynamic words delivered by backend requests. A section title, navigation caption or button can originate in Figma; a restaurant description or account status can arrive from an API. Those sources require different translation ownership.
A real-world situation
Imagine an itinerary app whose tab says ‘Saved places’ in French but whose saved records contain English place descriptions. The interface layer has changed while the content layer has not.
Where teams get into trouble: Auditing only design components gives a false sense of multilingual completeness because no one has checked the API payload or downstream messages.
A better approach: Create separate inventories for design strings, API fields, server errors and external communications. Assign an owner and translation method to each class before adding a second language.
What to verify: Open the same record in two languages and confirm its underlying identifier, availability and location are identical while approved display text varies.
A reliable translation is a promise about the next action, not just a replacement for a string. A reader should be able to predict what happens after tapping the control. If a label changes meaning while the underlying action stays the same, the interface has become less transparent even when its grammar is correct.
2. Check plan access without confusing a feature with a promise
Bravo’s help documents a multi-language integration under an eligible paid plan, currently described as Bravo Solo. Plan names and entitlements can change, so read the account’s actual settings rather than assuming every new or free project supports the same controls.
A real-world situation
A volunteer team designs twenty screens, then discovers that the multilingual integration is outside its budget for publishing the intended mobile experience.
Where teams get into trouble: A project can be technically translatable in theory yet financially or operationally blocked at the moment it must be shipped.
A better approach: Confirm feature access early; test a minimal translated screen in the account that will publish the final app. Budget for review, translated content and future updates, not simply the upgrade.
What to verify: Save the documented configuration and a reproducible proof of a translated screen, rather than using a sales page as acceptance evidence.
A screenshot can prove that a word appeared, but it cannot prove that the visitor understood the task. A useful test records what the person expected, what they selected and what the application actually did. The gap between those three observations is where language defects become visible.
3. Choose the original language before collecting translations
The original language is the authoritative text from which translators work. The Bravo integration asks for this language before target languages. A poor source sentence becomes harder to repair once several translated JSON files and backend descriptions have been created.
A real-world situation
Consider ‘Free cancellation until tomorrow’ on a booking screen. Without a cutoff time and time zone, translators cannot know what promise is being made.
Where teams get into trouble: Teams may translate fluent sentences that contain unresolved business ambiguity. Later corrections then require revisiting every target language.
A better approach: Rewrite critical source text into a precise, stable message. Specify any deadline, condition or exception in a product content specification before distributing translations.
What to verify: Ask two readers to explain the source-language cancellation condition independently and compare their answers to the actual backend policy.
The safest multilingual design keeps business facts separate from the words chosen to describe them. Stable identifiers, verified totals and permission rules should survive a locale change. Only presentation and legitimately localized content should vary. This distinction prevents translation from silently rewriting evidence.
4. Manage static-text JSON with deliberate keys
Bravo’s help explains that translated language files may be edited in the platform or uploaded as JSON. Treat them as governed content files: a key should map to one concept in a particular user-interface context, not to every unrelated use of the same English word.
A real-world situation
The English word ‘Save’ appears on a profile button and a document export screen. The target language may require different expressions because one saves preferences and the other saves a file.
Where teams get into trouble: A global search-and-replace can make one use correct while damaging another. A JSON file can also be syntactically valid but semantically wrong.
A better approach: Inspect each text occurrence and add context for ambiguous actions. Keep a reviewed copy of language files, maintain a change record and test each screen after importing.
What to verify: Verify key coverage and show both actions to an in-language reviewer who can explain the different outcomes.
The person encountering an error is often under pressure. Give them a recovery path in the same language, explain whether anything was saved and avoid claiming that a transaction succeeded until the system confirms it. Recovery messages deserve as much translation attention as welcoming text.
5. Design files are not the entire product
Figma or Adobe XD supplies static words and layout. Imported designs are only one part of the finished app. Background images, embedded text, icon meaning, touch targets and app navigation can remain culturally confusing after a string file is translated.
A real-world situation
A city-guide screen puts a translated heading beside a poster image containing English opening-hour instructions. The language file has no control over those pixels.
Where teams get into trouble: Teams may report full translation coverage even though decisive instructions are embedded in images or inaccessible as text.
A better approach: Review every visual asset that contains words, create appropriate language variants where needed and prefer real text components for instructions that must remain readable and accessible.
What to verify: Inspect the actual phone screen at larger font settings and ask whether all information needed for the next action is available in the selected language.
Internationalization is easier to maintain when every change has a known owner. A small edit to a default-language screen can affect multiple translations and devices. Treat new interface strings as a release change, not as harmless decorative copy, and revisit all supported language journeys.
6. Do not overclaim automatic device-language selection
Bravo’s help describes matching static translations to the phone’s language settings. Device locale is an initial signal, not proof of a person’s preferred reading language, especially on shared devices or in multilingual households.
A real-world situation
A Spanish-speaking parent borrows a phone configured in English and opens a school communication app. The app cannot safely infer their language preference from hardware settings alone.
Where teams get into trouble: A design that relies entirely on device inference may make the first screen hard to understand for the person who needs it most.
A better approach: Explain supported languages during onboarding, and where product capabilities permit a preference, test how it is stored and honored. Otherwise give clear practical instructions about device language settings.
What to verify: Check first launch on unsupported, bilingual and returning device profiles; record the visible fallback rather than presuming it.
An effective review distinguishes the platform’s documented feature from an application’s chosen implementation. An editor may expose a convenient language setting, but the product team still owns database responses, email templates, legal claims, accessibility and the meaning of outcomes. Never infer complete coverage from a settings page.
7. Use device.lang as an API input, not as translation magic
Bravo documents the built-in device.lang variable for outgoing requests. It can carry a device language code to a backend that knows how to return an appropriate variant. The variable does not rewrite the text in an arbitrary API response.
A real-world situation
A museum API receives a language parameter and returns the German description of an exhibit while preserving the exhibit’s ID and ticket availability.
Where teams get into trouble: Developers may add the variable to a URL but fail to store German descriptions, producing empty records or server errors.
A better approach: Define the supported codes and response behavior, pass the language safely to the API, and verify actual payload values for at least two locales.
What to verify: Compare request parameters and returned fields, including content language, record IDs, null values and structured errors.
A reliable translation is a promise about the next action, not just a replacement for a string. A reader should be able to predict what happens after tapping the control. If a label changes meaning while the underlying action stays the same, the interface has become less transparent even when its grammar is correct.
8. Normalize language codes at the backend boundary
Language conventions vary: some systems distinguish ‘en’ from ‘en-US’ or ‘pt’ from ‘pt-BR’. A device may report a broader or narrower code than the backend tables expect. A mapping rule should be explicit and predictable.
A real-world situation
A phone asks for Portuguese as spoken in Brazil, while the backend only stores one Portuguese description. The app must choose an approved policy rather than constructing a nonexistent table name.
Where teams get into trouble: Blindly inserting raw device codes into a collection name can create missing resources and unpredictable fallback behavior.
A better approach: Maintain a supported-language map, canonicalize codes as appropriate and return a documented default when a requested variant does not exist.
What to verify: Test realistic code variations, including an unsupported region, and verify the language actually returned in the response.
A screenshot can prove that a word appeared, but it cannot prove that the visitor understood the task. A useful test records what the person expected, what they selected and what the application actually did. The gap between those three observations is where language defects become visible.
9. Keep record identity stable across languages
Translated content should represent the same underlying object. Ideally a record has a stable ID and separate language variants of text, while price, permission, stock and status come from authoritative data rather than from independently translated copies.
A real-world situation
A traveler bookmarks place 84 in English and later opens the app in French. Their bookmark should still point to place 84, not to a second record created for the French description.
Where teams get into trouble: Duplicating full records for each language can accidentally duplicate counts, split reviews, change inventory or break favorite links.
A better approach: Use language-specific text values or related translation records linked by stable IDs, and validate that API endpoints preserve the same domain identity.
What to verify: Confirm bookmarks, ratings and permission checks survive locale changes without creating or discarding underlying records.
The safest multilingual design keeps business facts separate from the words chosen to describe them. Stable identifiers, verified totals and permission rules should survive a locale change. Only presentation and legitimately localized content should vary. This distinction prevents translation from silently rewriting evidence.
10. Plan unsupported-language behavior before launch
Bravo’s example warns that language-dependent backend tables may return errors when a locale has no corresponding resource. A safe product should predict that case instead of displaying a blank view or a success message with missing content.
A real-world situation
A device is configured for Finnish but the travel app supports only English, Spanish and French. The API must still produce a usable and honestly labeled experience.
Where teams get into trouble: A 404 response may be shown as ‘no destinations’ or an empty list, misleading users about actual inventory.
A better approach: Choose a known fallback locale, map unsupported requests deliberately and distinguish content-not-translated from content-not-found.
What to verify: Test the unsupported locale with actual network requests; verify the fallback heading, records and error explanations are mutually consistent.
The person encountering an error is often under pressure. Give them a recovery path in the same language, explain whether anything was saved and avoid claiming that a transaction succeeded until the system confirms it. Recovery messages deserve as much translation attention as welcoming text.
11. Translate navigation as a complete journey
A native app usually combines tabs, lists, detail screens, modals and external links. The useful unit of localization is the path between them. A translated landing page is not enough if the user cannot understand the next screen.
A real-world situation
Someone opens a translated hotel list, selects a hotel, enters check-in dates and reaches an English cancellation confirmation. The final screen carries more risk than the welcome screen.
Where teams get into trouble: Static-translation completion reports can miss components created by plugins or dynamic responses loaded only after an action.
A better approach: Walk through the same journey from start to finish in each locale, including back navigation and cancellation. Record where language changes unexpectedly.
What to verify: Collect screen-by-screen evidence that the person can complete the intended task without switching back to the default language.
Internationalization is easier to maintain when every change has a known owner. A small edit to a default-language screen can affect multiple translations and devices. Treat new interface strings as a release change, not as harmless decorative copy, and revisit all supported language journeys.
12. Treat validation and backend errors as content
Empty fields, expired sessions, payment rejections and timeouts often produce messages outside the main design. A complete localization plan covers these states and makes recovery understandable.
A real-world situation
A user enters an invalid postal code. The field label is translated, but the error says ‘invalid address schema’ in a backend engineer’s English.
Where teams get into trouble: A polished translated interface may become unusable exactly when someone makes an error or loses connectivity.
A better approach: Inventory validation strings and convert backend error codes into approved human messages at the presentation boundary, without disguising actual failure.
What to verify: Trigger deliberate invalid submissions and verify users can identify what to correct without guessing.
An effective review distinguishes the platform’s documented feature from an application’s chosen implementation. An editor may expose a convenient language setting, but the product team still owns database responses, email templates, legal claims, accessibility and the meaning of outcomes. Never infer complete coverage from a settings page.
13. Language must not become an authorization rule
Choosing a language should not give access to a different person’s records or move the user between security roles. Authentication and authorization are independent of localized labels or a device.lang request parameter.
A real-world situation
A club app displays membership status in German. The user switches to English and should still see only their own membership and invoices.
Where teams get into trouble: If a backend query accepts language and account parameters without independent access enforcement, cross-locale requests can expose private data.
A better approach: Test server-side authorization with two different accounts and several locales. Keep credentials and permission checks separate from translation.
What to verify: Verify a forbidden record stays forbidden in every language, including when the request URL is modified.
A reliable translation is a promise about the next action, not just a replacement for a string. A reader should be able to predict what happens after tapping the control. If a label changes meaning while the underlying action stays the same, the interface has become less transparent even when its grammar is correct.
14. Keep form values distinct from translated labels
A form can present ‘Other’, ‘Morning’ or ‘Confirmed’ in different languages while saving a stable enum value in the backend. The presentation label is not a safe universal database key.
A real-world situation
A volunteer selects a Spanish-labelled morning shift. The stored value should remain the agreed shift identifier, not a string that reporting logic cannot recognize.
Where teams get into trouble: Saving localized display strings as system codes can break analytics, automation and integrations when the selected language changes.
A better approach: Bind controls to stable coded values and translate only what the user sees. Confirm outgoing payloads with the API during testing.
What to verify: Compare two submissions in different locales and verify that they create equivalent structured data.
A screenshot can prove that a word appeared, but it cannot prove that the visitor understood the task. A useful test records what the person expected, what they selected and what the application actually did. The gap between those three observations is where language defects become visible.
15. Verify dates, numbers and prices independently
Language translation and regional formatting are related but not identical. A currency symbol, decimal separator or time format can change interpretation without changing a single sentence.
A real-world situation
A ticket costs 1,250 in one currency. A poorly formatted value may be read as one point two five or one thousand two hundred fifty depending on locale conventions.
Where teams get into trouble: Formatting a displayed number differently from the authoritative charge creates disputes even when the translated button caption is perfect.
A better approach: Use locale-aware formatting where supported; specify currency codes and time zones for high-stakes actions. Validate against the payment or reservation source of truth.
What to verify: Ask readers to say the amount, currency and deadline aloud and compare with the real transaction.
The safest multilingual design keeps business facts separate from the words chosen to describe them. Stable identifiers, verified totals and permission rules should survive a locale change. Only presentation and legitimately localized content should vary. This distinction prevents translation from silently rewriting evidence.
16. Design for long strings and mixed scripts
Localized words can occupy different amounts of space; some languages require more characters, different line breaks or different reading directions. Native design components should tolerate that variation.
A real-world situation
A German primary action wraps onto three lines and overlaps a small icon in a narrow phone layout. The text is semantically correct but practically hard to tap.
Where teams get into trouble: Design reviews that use only short English labels often miss clipping, hidden accessibility text and touch targets displaced by line wrapping.
A better approach: Test realistic longest approved strings and large system font sizes. Check right-to-left scenarios where supported and verify actual user interaction.
What to verify: Save device screenshots showing readable text, visible controls and unambiguous tap targets, rather than relying on design-file dimensions.
The person encountering an error is often under pressure. Give them a recovery path in the same language, explain whether anything was saved and avoid claiming that a transaction succeeded until the system confirms it. Recovery messages deserve as much translation attention as welcoming text.
17. Support readers who use assistive technology
Translation includes accessible names, hint text, focus order and alt text. A visually translated button may still be announced incorrectly by a screen reader if its accessibility description is not localized.
A real-world situation
A tourist using spoken feedback hears an English icon label on a Spanish screen and cannot tell whether the button opens directions or starts payment.
Where teams get into trouble: A visual-only review overlooks barriers that prevent users from discovering controls or knowing the result of an action.
A better approach: Test platform accessibility features in the native app, particularly screen reader names, enlarged text and focus after dynamic updates.
What to verify: Have the tester describe the action from the accessibility announcement without looking at the screen.
Internationalization is easier to maintain when every change has a known owner. A small edit to a default-language screen can affect multiple translations and devices. Treat new interface strings as a release change, not as harmless decorative copy, and revisit all supported language journeys.
18. Do not rely on API success alone
A successful HTTP response confirms that a server answered according to its protocol, not that the requested language is present or that the text means the right thing.
A real-world situation
The API returns status 200 and a French locale indicator, but the description field contains an untranslated English paragraph left from a migration.
Where teams get into trouble: Translation defects can pass technical tests because data structures remain valid while reader meaning is wrong.
A better approach: Add content-language and completeness checks, plus sampling by bilingual reviewers. Treat meaningful language validation separately from request uptime.
What to verify: Inspect representative response bodies and have reviewers verify that key content makes the same factual claims.
An effective review distinguishes the platform’s documented feature from an application’s chosen implementation. An editor may expose a convenient language setting, but the product team still owns database responses, email templates, legal claims, accessibility and the meaning of outcomes. Never infer complete coverage from a settings page.
19. Preview with Bravo Vision, then validate release behavior
Bravo’s documentation points to Bravo Vision for testing an app and its features. Preview is essential, but release builds and actual store distribution may introduce different configuration, caching or notification behavior.
A real-world situation
An update appears in Bravo Vision after syncing, yet a previously installed release still contains the older translated strings until the next appropriate deployment.
Where teams get into trouble: Teams can mistake successful preview behavior for evidence that all shipped users already received the change.
A better approach: Test in Bravo Vision, document the sync state and repeat critical language journeys on release-equivalent installations before making promises to users.
What to verify: Record app version, device language, dataset version and observed screen behavior for every release acceptance test.
A reliable translation is a promise about the next action, not just a replacement for a string. A reader should be able to predict what happens after tapping the control. If a label changes meaning while the underlying action stays the same, the interface has become less transparent even when its grammar is correct.
20. Localize the edges of the mobile experience
The screen is only one surface. Push notifications, app-store descriptions, support pages and post-submission emails may be managed by separate platforms and teams.
A real-world situation
A customer reads a French booking flow but receives an English confirmation email with a different date convention. They may wonder which statement is authoritative.
Where teams get into trouble: An app can be translated internally yet still send confusing messages when it reaches outside services.
A better approach: Inventory all external messages, store listing text and deep-link destinations. Assign owners and tests; do not infer that Bravo’s static translation JSON governs them.
What to verify: Trigger real test notifications and emails and compare their meaning to the confirmed backend state.
A screenshot can prove that a word appeared, but it cannot prove that the visitor understood the task. A useful test records what the person expected, what they selected and what the application actually did. The gap between those three observations is where language defects become visible.
21. Separate what was requested from what succeeded
Localization must preserve transaction status accurately. Phrases such as ‘sent’, ‘received’, ‘approved’ and ‘completed’ mean different things across workflow states.
A real-world situation
A translated donation app says ‘payment complete’ immediately after the user taps Submit, even though the payment provider later declines the charge.
Where teams get into trouble: Overconfident success messages damage trust because fluent translation masks a false business claim.
A better approach: Map approved strings to explicit application states, including pending, failed, retryable and complete, and confirm which source owns each state.
What to verify: Use deliberately delayed and rejected test requests to confirm messages tell the truth about the transaction.
The safest multilingual design keeps business facts separate from the words chosen to describe them. Stable identifiers, verified totals and permission rules should survive a locale change. Only presentation and legitimately localized content should vary. This distinction prevents translation from silently rewriting evidence.
22. Assign responsibility for future changes
Translation is a maintained relationship between source text, language variants, data, and user expectations. When the product changes, that relationship must be revisited.
A real-world situation
A new membership tier adds one checkbox. Designers update the English screen, but no one updates the equivalent warning in Spanish.
Where teams get into trouble: This is how multilingual coverage decays: not through one dramatic mistake but through small unreviewed product changes.
A better approach: Include language coverage in feature tickets and release review, with explicit responsibility for design text, API copy, notifications and screenshots.
What to verify: Check that every modified user-visible concept has corresponding reviewed target-language variants before shipping.
The person encountering an error is often under pressure. Give them a recovery path in the same language, explain whether anything was saved and avoid claiming that a transaction succeeded until the system confirms it. Recovery messages deserve as much translation attention as welcoming text.
Practice workshop: complete journeys rather than isolated screens
1. The first launch on an unsupported device
Configure a device to use a language the app does not advertise. Open the app with no existing account or cached session and record what the first screen and API list say.
Inspect the actual fallback policy. If the backend rejects device.lang codes outside a narrow set, route the request to the documented supported default, not to an invalid table. State available languages plainly and avoid claiming that an unsupported language is provided.
An acceptable result looks like this: The visitor sees a coherent usable default and can understand that some language choices are unavailable.
Repeat the exercise in the default language and the second language, on a fresh installation or browser profile as appropriate. Compare the same underlying record and action. Note any difference caused by translation separately from differences caused by permissions, caching, connectivity or regional business rules.
2. The saved item after a language change
Save a listing in the default language, then open the same installation with another supported device language and return to Saved.
Compare the stable listing ID, ownership and availability with both responses. Translate descriptions and headings, but never create a new item merely because the source label differs.
An acceptable result looks like this: The bookmark still works and the correct translated record appears.
Perform the action once with valid data and once with an intentionally invalid or incomplete input. Then try a return visit. Keep the test account and data stable, record the actual system result, and ask a reader to explain the message without seeing the source-language original.
3. An API outage in the second language
Open a screen that depends on an external data collection, then simulate a failed request after static UI text has loaded.
Check the source of empty-state and retry messages. The user must understand whether content is absent, untranslated, unreachable or temporarily delayed; these are different problems.
An acceptable result looks like this: The app describes the real failure and offers an understandable next step without fabricating a result.
Repeat the exercise in the default language and the second language, on a fresh installation or browser profile as appropriate. Compare the same underlying record and action. Note any difference caused by translation separately from differences caused by permissions, caching, connectivity or regional business rules.
4. The booking deadline across time zones
Prepare a fictional reservation with a fixed cutoff timestamp and show it to readers in different regions.
Specify the time zone or local conversion rule, verify the amount and deadline against the backend and ask each tester to repeat what they believe is required. Do not translate an ambiguous ‘tomorrow’ literally.
An acceptable result looks like this: Both readers understand the same underlying contractual deadline.
Perform the action once with valid data and once with an intentionally invalid or incomplete input. Then try a return visit. Keep the test account and data stable, record the actual system result, and ask a reader to explain the message without seeing the source-language original.
5. The two-account access test
Create two test users with different permissions and record owners, then switch languages while inspecting a protected detail screen.
Confirm permission enforcement happens on the server for every API request, independent of device.lang. Intentionally try a valid record ID belonging to the other user.
An acceptable result looks like this: No unauthorized data appears and denial is explained in the selected language.
Repeat the exercise in the default language and the second language, on a fresh installation or browser profile as appropriate. Compare the same underlying record and action. Note any difference caused by translation separately from differences caused by permissions, caching, connectivity or regional business rules.
6. A long-text mobile layout
Replace short labels with reviewed long-language variants on a compact phone and enable the device’s large-text setting.
Watch for clipped actions, invisible field hints, overlapping icons and unreachable controls. A screenshot alone is insufficient; ask the tester to complete the journey using the enlarged text.
An acceptable result looks like this: Text and actions remain readable and operable rather than merely aesthetically tidy.
Perform the action once with valid data and once with an intentionally invalid or incomplete input. Then try a return visit. Keep the test account and data stable, record the actual system result, and ask a reader to explain the message without seeing the source-language original.
7. The source-data correction
Correct a factual error in the default description of a museum exhibit that already has several translated variants.
Track which translated descriptions need reapproval. Do not let the wrong localized description remain after the source change; identify how the app caches records across sessions.
An acceptable result looks like this: Every locale eventually shows the corrected factual statement with the same object identity.
Repeat the exercise in the default language and the second language, on a fresh installation or browser profile as appropriate. Compare the same underlying record and action. Note any difference caused by translation separately from differences caused by permissions, caching, connectivity or regional business rules.
8. A false-success challenge
Have a test backend return pending and rejected outcomes for a form that normally completes quickly.
Verify the interface shows distinct pending, failed and confirmed messages. Do not map a successful network connection to successful payment or approval.
An acceptable result looks like this: The status a user sees matches the authoritative outcome.
Perform the action once with valid data and once with an intentionally invalid or incomplete input. Then try a return visit. Keep the test account and data stable, record the actual system result, and ask a reader to explain the message without seeing the source-language original.
9. A notification outside the app
Trigger a sample account update and capture the push alert, in-app destination and follow-up email for both supported locales.
Check the system responsible for each surface. The static UI language file may not affect external delivery. Compare amounts, dates, recipients and access restrictions.
An acceptable result looks like this: The customer receives a coherent series of messages without contradictions.
Repeat the exercise in the default language and the second language, on a fresh installation or browser profile as appropriate. Compare the same underlying record and action. Note any difference caused by translation separately from differences caused by permissions, caching, connectivity or regional business rules.
Four-week practical rollout
Week 1: Inventory and decisions
Walk through the complete app, separating design text, backend fields, errors, messages and transactional states. Define what the product will actually support by language and device. Resolve unclear source phrases before asking anyone to translate them.
Confirm the subscription feature, available test devices and the person who owns backend language logic. Record an explicit fallback policy and stable IDs for any localized records.
Week 2: Translation and integration
Set up original and target languages in the documented integration. Review static text JSON by screen and action; configure API language values, supported codes and fallback responses. Keep private data and authorization outside translation logic.
Use a deliberately small end-to-end slice before expanding. The first complete journey should include a list, detail page, form, error and verified success state.
Week 3: Failure and accessibility testing
Test unsupported locales, slow networks, invalid inputs, larger font sizes, mixed scripts, mobile navigation and longer words. Compare API responses against the UI and include bilingual review of high-risk actions.
Inspect assistive-technology announcements and translated visual assets. Repeat tests on a real device in Bravo Vision and a release-equivalent build as appropriate.
Week 4: Release and maintenance
Confirm the actual build version and review what appears in stores, notifications and emails. Retest key user journeys after source or data changes; assign owners for any newly introduced strings.
Document unresolved limitations honestly. Release when customers can complete the task safely, not when a spreadsheet reports that every key contains some text.
Frequently asked questions
Does Bravo Studio support multilingual apps?
Bravo’s help documents a multi-language integration for eligible plans. Check the account’s current capabilities and the latest documentation before committing to a production workflow.
Does it translate the whole backend automatically?
No. Its documented dynamic-text approach relies on your backend providing language-specific values and an appropriate API request. A language variable is a request input, not a translation engine.
Where do static translations live?
Bravo describes files for the added languages that can be edited in the platform or provided as JSON. Keep a reviewed version and verify both the words and their use in context.
What is device.lang?
It is a built-in language variable documented by Bravo for use in API requests. Map returned codes to backend-supported language variants and test unsupported values.
Will a device language preference always be right?
Not necessarily. A person’s preferred reading language may differ from the device configuration, especially on shared or multilingual devices. Make supported options understandable.
Can a translated label change a database value?
It should not. Stable record IDs, state codes and permission rules should remain independent of presentation language.
How do I test actual screens?
Bravo documents Bravo Vision as a preview tool. Use it to inspect real interaction, then verify release-equivalent native behavior where the deployment differs.
What about app-store search?
App-store metadata is a separate delivery surface and must be handled according to the relevant store. Do not assume in-app translations rewrite listings.
Does HTTP 200 prove translation quality?
No. It confirms the request succeeded technically, not that the returned words are in the correct language or preserve the intended meaning.
What is the most valuable final test?
Give an unfamiliar person a complete task in the target language and verify that they can predict and confirm the real outcome without being coached.
What successful localization should feel like
A well-localized Bravo app makes its boundaries invisible to the reader without hiding them from its builders. The design, the API and every downstream message tell the same story. A user can find the right item, understand a choice, correct an error and trust the result without knowing which layer originally supplied the words.