Localize an Offline AI Workflow

Direct answer

An offline AI app has more than one language state. The interface locale determines resource selection and formatting; a user task may have a source and target language; a model or runtime may have its own supported-language evidence; and a fallback route may behave differently again. Treat these as separate fields in the product and test record. Android's localization system selects resources according to locale configuration and needs a complete default resource set. Its per-app language preferences let users choose an app language separately from device language on supported platform versions. Neither feature proves that a model can translate between two languages. ARCH-01 and BENCHMARK-01 support keeping architecture and evaluation evidence separate; they do not certify any Cove language capability. Start with a language-state table before running tasks. Record device locale, selected app locale, available UI resources, source language, target language, prompt language, artifact identity, and the evidence supporting model capability. An English interface with a Japanese source and Chinese target is one combination; it is not equivalent to a Japanese interface or a model that supports either language. A language picker is a user selection, not proof of runtime acceptance. If support is unknown, preserve an explicit unknown or unsupported state rather than copying the UI locale into a model-capability field. Test UI localization as its own workflow. Exercise first launch, language change, process recreation, settings return, notification text if used, empty states, permission education, errors, cancel flows, and accessibility labels. Check plural resources, date and number formatting, text expansion, truncation, and fallback to default resources. Android resource resolution may choose a fallback when an exact locale resource is not present, so the test should record which string actually rendered. Do not use a translated screenshot as evidence that prompts, generated text, or model outputs use that language. Then test task-language behavior independently with versioned fixtures. Prepare source text and target expectations with a qualified reviewer before a run; keep the model artifact, tokenizer, prompt, and preprocessing fixed. Record unsupported language input, mixed-script text, direction changes, and user edits as individual outcomes. If a result is rejected, report the task state without changing the UI locale. If a prompt contains instructions translated into another language, that is a separate prompt revision and should not be silently bundled into localization changes. Fallback is a user-visible boundary. A missing translation resource can fall back to a default string; a missing model asset can block an inference task; a network fallback may send data elsewhere. Do not present these as one generic language fallback. Define whether the app leaves the source text unchanged, asks the user to choose a supported route, or fails with an explanation. If a remote service is available, disclosure and consent must precede transfer. If no fallback exists, say that rather than inventing a successful translation. For reproducibility, pin locale lists and app resource revision with the test build. On Android 13 and later, per-app language settings have platform behavior and configuration requirements; older versions may use AndroidX or custom selection. Record OS version and actual selected locale rather than relying only on a preferences screen. Check after process restart and app update that the selected UI locale persists as intended without silently changing source or target language. Also check that library resources do not expose a locale that the app has not reviewed. The report should make a matrix with rows for UI locale, task source/target, model evidence, prompt revision, and fallback. Keep positive and negative cases, including unsupported tasks and incomplete translations. Do not state that a language is supported because an app string exists, because a locale appears in system settings, or because another model in the same family handled it. This separation helps reviewers determine whether a failure belongs to resources, task setup, capability evidence, or fallback design. It is a test and audit method, not a claim about Cove or a particular model's multilingual ability.

A traveler changes the app language before starting translation

A traveler keeps the phone system in English but selects a different app interface language before entering a phrase in one language and requesting another. The interface change must not silently alter the source or target, and the product team must know whether the chosen model route has evidence for that pair.

Decision

Record UI locale, task languages, model evidence, and fallback separately, then test the whole state transition on the exact Android version.

Expected outcome

The test shows which interface resources rendered and whether the separate task route was supported, unsupported, or unverified.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Locale coverage table
• Language-specific fixtures
• Unsupported-language behavior

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Create a language-state matrix. List device locale, app locale, source and target, prompt revision, artifact identity, evidence status, and fallback route as separate fields.
2. Exercise resource selection and fallback. Change app locale, restart the process, revisit settings, and inspect rendered strings, plural forms, dates, numbers, errors, and missing-resource defaults.
3. Run task fixtures without changing UI locale. Use pre-reviewed source and target fixtures with fixed artifact and prompt, then record accepted, rejected, mixed-script, and unsupported outcomes against predefined criteria.
4. Test every failure and fallback boundary. Remove a test resource or asset, deny network where applicable, and verify the interface explains each distinct state without hidden transfer.
5. Review persistence and release metadata. Repeat after app update and process recreation; capture OS, resource revision, selected locale, task pair, and exact evidence for the release record.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• UI locale, task source/target, model evidence, prompt language, and fallback are separately represented and tested.
• Missing UI resources, unsupported task languages, missing assets, and network fallback produce distinct user-visible states.
• No language-support claim is inferred from translated UI strings, a language picker, or a different artifact.

Decision table

Failure patterns to prevent

• Translating UI only
• Advertising untested model languages

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• On-device AI architecture overview
• Cove benchmark method
• Android localization guide
• Android per-app language preferences
• Android multilingual resource resolution

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions