Offline Hebrew Translation and RTL Layout Test

Direct answer

An RTL test should separate text direction from application layout direction. Android can infer layout direction from locale, and Compose uses relative start/end concepts, but a translated string is not enough to prove a working Hebrew screen. Text can contain Hebrew, Latin model names, numbers, URLs, and punctuation together; visual order and logical text order must both remain understandable. ARCH-01 and BENCHMARK-01 support a source-backed test methodology, not a Cove Hebrew-support statement. Start by recording the actual UI locale, text direction, layout direction, source and target fields, and the widget displaying each string. Hebrew text in an English interface is not the same test as a fully RTL interface. Likewise, mirroring an app bar does not guarantee that text selection, cursor movement, a mixed Latin serial number, or an exported file behaves correctly. Keep a distinction between the direction in which the UI is arranged and the bidirectional algorithm used to display each text run. Build a corpus with reviewed Hebrew phrases and controlled mixed-direction cases: Hebrew with a Latin product name, a web address, a date, a decimal or version number, paired parentheses, quotation marks, punctuation at both ends, and a line that wraps. Include empty, long, and user-edited values. A qualified Hebrew reader should check intended reading order and meaning; a developer should record logical source string, code points where useful, and displayed output. Never reorder source text manually to make a screenshot appear correct. Test Android resource direction and app configuration using official guidance. Verify RTL support settings and use logical start/end positioning rather than hard-coded left/right assumptions where appropriate. Check icons individually: a back arrow or directional navigation control may need mirroring, while a play icon or brand mark may not. The platform's resource mirroring rules do not determine the meaning of every asset. Capture screen state, locale, API version, and relevant component so another reviewer can reproduce the observation. In the translation workflow, inspect source input, translated draft, error text, loading state, and retry state. Verify the caret and selection when the user edits mixed text; confirm copying or export preserves logical characters, punctuation attachment, and line breaks. Test accessibility reading order as well as visual order. If an output is unsupported, show a truthful status rather than using a fallback language that looks plausible but changes meaning. A visually mirrored layout cannot establish semantic translation quality. Do not claim a model supports Hebrew based on UI rendering, a locale label, or an RTL preview. Language capability requires exact artifact, source-target direction, task fixtures, and an evaluation record. This guide tests a rendering and interaction boundary regardless of model outcome. If no validated Hebrew output exists, the team can still test localized static strings and controlled synthetic direction fixtures, while leaving model capability as unknown. The report should include device and OS, app build, locale, layout direction, test corpus version, widget, visual and logical checks, selection/copy/export outcomes, and reviewer notes. Preserve both failures and pass results. RTL bugs can be selective: one screen may mirror while an embedded field stays left-aligned, and one string may show correctly while its selection offsets fail. A matrix makes that coverage explicit. Keep the claim limited to the examined interface and build; it is neither a general Hebrew-support certification nor a translation-accuracy benchmark.

A bilingual traveler edits a Hebrew phrase with an embedded booking code

A traveler sees a Hebrew phrase beside a Latin booking code and a date, then edits one word before copying the result into a message. The screen is intended to follow an RTL locale, but the code and punctuation must remain readable and in logical order.

Decision

Check layout mirroring, bidirectional text, cursor selection, and copy output separately with a Hebrew reviewer and a fixed mixed-text fixture.

Expected outcome

The report identifies the exact UI behaviors observed without claiming a Hebrew translation model is supported.

Evidence to collect

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

• Hebrew bilingual fixtures
• RTL interaction screenshots
• Offline completion and layout failures

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

Implementation workflow

1. Record locale and direction state. Capture device and app locale, layout direction, individual text direction, widget type, Android version, and whether the string is original or generated.
2. Prepare a reviewed mixed-direction corpus. Include Hebrew, embedded Latin identifiers, numbers, URLs, paired punctuation, long lines, wrapping, empty values, and edited versions with annotated reading order.
3. Inspect rendering and interaction. Check reading order, alignment, mirroring, cursor movement, selection handles, copy, paste, retry, and export in the exact screen state at fixed widths.
4. Compare logical text with display. Preserve the input string and inspect its logical order alongside rendered output; never rewrite the underlying text to make a screenshot look right.
5. Document unsupported and failed cases. Record component-level failures and reviewer notes, separate UI localization from model evidence, and leave unverified language capability unknown after review.

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

Acceptance criteria

• The test distinguishes locale-driven layout direction from text-level bidirectional rendering and records both.
• Mixed Hebrew, Latin, numeric, and punctuation fixtures preserve intended reading order through edit, copy, and export.
• The report makes no Hebrew model support or translation-quality claim unless a separately reviewed artifact evaluation exists.

Decision table

Failure patterns to prevent

• Testing translation text without the UI
• Assuming every RTL control behaves alike

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 support for different languages and cultures
• Android right-to-left resource and layout guidance
• Android layout direction API

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

Frequently asked questions