If an app still displays the wrong language after you change a phone’s locale, do not start by tapping different coordinates. Check the device locale, the app’s own language preference, the installed language resources and any account-side preference. They are separate inputs and can disagree.
Likewise, a German language setting does not imply a German IP address, a German account region or a particular timezone. The regional settings guide introduces those controls; this article focuses on diagnosing the visible result when a localization test fails.
Establish a baseline you can compare
Use the same owned app build and a harmless test account. Record the visible screen, the device settings returned by the API and the text you expected to see. If you are comparing languages, hold unrelated inputs fixed before changing one variable.
curl --fail-with-body -X PATCH "$MSB/v1/phones/$ID/device" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY" \
-H 'Content-Type: application/json' \
-d '{"locale":"de-DE","timezone":"Europe/Berlin"}'
curl --fail-with-body "$MSB/v1/phones/$ID/device" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY"The phone must be ready for configuration. Inspect the response and reopen the app when its own resource handling requires it. Then observe the screen again rather than assuming a successful settings request guarantees every application immediately changed its content.
Check app language before reinstalling
Android supports a per-app language preference for applications that participate in the feature. Android’s app-language documentation describes how that preference can differ from the system language. An app may also expose its own language selector or use an account preference fetched from its server.
If the system changed but one app did not, inspect that app’s language setting. If text loaded from an account stays in English while local buttons become German, separate remote content from Android resource selection. A server-rendered description and a native button label can have different sources.
Confirm that the translation is installed
A split APK bundle can contain language-specific resources. The selected installed splits and the device locale matter together. Changing locale cannot create a translation that the app build does not include.
Android’s localization guide explains the role of resource files and fallback behavior. For Mobilebox’s upload and split-selection path, use the installation guide. Reinstall only when changing the installed package/resource set is the intended test; uninstalling first can erase local app state and introduce another variable.
Treat formatting as a separate assertion
| Symptom | Investigate |
|---|---|
| One app ignores system language | Per-app or in-app language setting |
| Some labels translated, others unchanged | Available resources, fallback or remote content |
| Correct language, wrong displayed time | Timezone and the application’s time source |
| Correct locale, unexpected market availability | Account rules and network/region logic |
| Tap by old English text fails | New translated label or stable resource id |
For UI automation, locale changes also invalidate assumptions in your action plan. Prefer a stable resource-id target when the app exposes one; otherwise read the translated current label. A reference from the earlier-language screen should not be carried into the new layout.
Keep the result reproducible
For a localization bug report, include the app package/version, effective device settings, app-language preference, relevant installed resources and the observed text. Add a screenshot for layout or truncation issues. Avoid claiming that changing locale proves network geography or account eligibility.
Repeat the check after process restart when persistence matters, and use a fresh sandbox when testing first-run language selection. The state lifecycle guide helps keep those scenarios separate; the API reference defines the supported configuration fields.