Bulk Translation with an On-Device Model

Direct answer

A reliable on-device translation batch is a coordinator for many independent items, not one oversized prompt containing every document. Give each item a stable identifier and preserve its source, target language direction, source revision, and output state. Process work in bounded units that fit the chosen runtime contract, and store completed outcomes before advancing the batch. This makes partial success explicit: if item 18 fails, the app can show which earlier items finished and which later items remain queued rather than discarding the entire run or presenting an incomplete export as complete. Separate batch state from item state. A batch can be queued, running, pausing, cancelled, partially complete, failed, or complete. An item can be pending, translating, needs review, completed, failed, or skipped with a reason. Cancellation should stop scheduling new items and request cancellation of the active inference using the runtime contract; it should not mark already completed results as failed or assume a native operation stopped merely because a UI screen closed. Retain enough state to resume safely after process recreation if the product promises that behavior. Define chunking from application constraints and the actual model interface, not from a universal document-size rule. A document may need semantic or structural boundaries; splitting by arbitrary character count can separate headings, table cells, or context that affects meaning. Preserve chunk order and source offsets, record where boundaries were introduced, and provide a review step for merged output. Do not silently remove formatting, references, or untranslated spans. The method can recommend collecting resource evidence, but without raw device runs it cannot supply a maximum file size, throughput, completion time, thermal result, or battery estimate. Treat retries as item-level decisions. Retry only a classified transient or user-correctable condition, keep the original failure record, and avoid automatic loops. A repeated request should not duplicate export rows or lose the provenance of a previous output. Store the artifact revision, prompt or instruction revision, runtime identity, and parser version alongside each result so a batch can be audited later. When those facts are unavailable, mark them unknown instead of attributing every result to the current model. A partial export should include a manifest of item identifiers, order, statuses, and omissions. It should label itself partial and avoid substituting blank translations for failed items. If the user edits a translated result, distinguish model output from reviewed output. If an output format cannot represent partial states, ask the user to retry, export completed items separately, or cancel; do not silently create a misleading complete-looking file. Offline-first design means the local data source can serve the feature without requiring a remote inference call, but local execution does not automatically guarantee that every input file is available, every language pair is supported, or every task is finished. Test with network denied, a fresh batch, process interruption, missing assets, cancellation, and partial failure. Android thermal status can be observed as a platform signal on supported APIs, but it is not a measurement of model speed or a universal threshold. Report only the exact workload and device observations collected.

A user queues a folder of documents before a flight

A user selects a set of travel documents while connected, then expects to translate them after boarding. One file has an unsupported format, a later inference is cancelled, and the user may close the screen while the batch is running. The app needs to preserve completed items and make the remaining work understandable without promising a completion time.

Decision

Represent the operation as an ordered batch of separately recoverable items, verify required local inputs before starting, and make cancellation, retry, and partial export visible at both batch and item level.

Expected outcome

The user can continue with completed translations, retry or skip a failed file, and see which items are incomplete. No throughput, battery, or universal offline-support claim is inferred.

Evidence to collect

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

• Versioned document batch
• Per-item state schema
• Sustained, partial-failure, and resume records

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

Implementation workflow

1. Create a stable batch manifest. Assign each source a stable item ID, order, content revision or safe digest, detected format, target direction, and selected local artifact. Preserve names or metadata only when needed and avoid placing private document text in diagnostic logs.
2. Validate items and plan bounded work. Check that each input can be read and decoded, identify unsupported formats before expensive work, and split only at boundaries the product can reconstruct. Record chunk ordering and source offsets; do not promise one universal maximum size without device evidence.
3. Persist item outcomes as work proceeds. Save each item state and completed output before moving to the next. Track pending, running, needs-review, completed, failed, and skipped outcomes separately from batch status so a process interruption does not erase partial success.
4. Implement cancellation and selective retry. Stop scheduling on batch cancellation and propagate a stop request to the active inference owner. Retry only after a classified condition or user action, preserve the prior attempt, and use stable output keys to prevent duplicate rows.
5. Build a truthful partial export and review path. Include item order and status in the export manifest, mark incomplete batches as partial, and let the user export completed items separately or retry failures. Distinguish raw model text from edited or approved translations.
6. Test offline and sustained behavior without guessing. Use synthetic documents to test blocked network, missing local assets, app recreation, interrupted items, and repeated work. Record device, artifact, runtime, workload, and available thermal signals for any measurement; do not invent speed, battery, or temperature results.

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

Acceptance criteria

• Every selected item has a stable identifier, ordering, direction, and explicit status; unsupported inputs remain visible with a reason.
• Cancellation stops future scheduling and requests active-work cancellation while preserving completed results and prior attempt records.
• Exports identify partial completion and omissions, and all performance or thermal statements are limited to real recorded runs.

Decision table

Failure patterns to prevent

• One giant prompt for every file
• Dropping failed items from export

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
• Android Developers: Build an offline-first app
• Android PowerManager thermal status API

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

Frequently asked questions