Localize Credential Provider and Autofill Extensions Without Leaving English Fill UI

A multilingual password or passkey product can ship a polished vault, onboarding, and Settings screens and still show English credential lists, English generate-password chrome, or truncated translated actions when Autofill opens. The usual cause is not a missing host translation. The Credential Provider extension and the Android AutofillService own those strings. The host String Catalog never paints them unless the extension or service ships localized resources the OS can load.

Put Autofill on the same release bar as the vault. Inventory extension chrome separately from the container, localize Settings enablement and dataset presentations on purpose, and verify the fill UI after real Language and Region changes.

Why Autofill chrome drifts from the vault language

A credential manager has two owners. The container app owns the vault browser, sync status, and account screens. The operating system hosts Autofill beside login fields and lists the manager under Passwords / Autofill services in Settings. Apple's ASCredentialProviderViewController is the view controller a Credential Provider Extension uses to extend AutoFill. The Authentication Services framework covers passwords, passkeys, and related AutoFill integration. Android's AutofillService is bound by the system only after the user enables it, and fills screens through onFillRequest responses built from Dataset objects with presentation UI.

The localization gap shows up in five places:

1. Host UI strings live in the app target's catalog. Credential-list chrome, empty states, unlock prompts inside the extension, and generate-password screens often live only in the Credential Provider or AutofillService target.
2. Optional Settings configuration UI shown when someone first enables the manager is an extension surface, not a normal in-app settings row.
3. Android dataset presentations use RemoteViews layouts the system draws above the keyboard. Those layouts resolve resources from the service package, not from the vault Activity.
4. Xcode scheme Application Language can make the vault look correct while the simulator device language still leaves the extension on English.
5. Hardcoded English literals such as "Create & Autofill", "Passwords", or "No matching logins" never reach translators because they never lived in a catalog the extension loads.

Practitioner reports line up with that split. A Proton Pass pull request describes a German localization that made the Create & AutoFill button too wide inside the Autofill UI so other controls, including close, became unreachable. That is a text-expansion failure on the OS-hosted fill surface, not a vault-browser defect. A Bitwarden iOS change implements password generation UI in the AutoFill extension through CredentialProviderViewController, which is library- and product-specific evidence that generate-password and related Autofill entry points are treated as their own UI surface. Those reports describe specific projects, not a universal OS defect. They still surface the integration questions your workflow must answer.

General iOS localization guides, including Phrase's iOS localization overview and the live i18nAgent iOS guide, cover catalogs and UI strings. They do not connect Credential Provider bundles to Settings enablement UI and Android dataset presentations. The Android localization guide likewise stops short of AutofillService presentation labeling. Biometric prompt copy and share-extension localization covered elsewhere are different problems: a Face ID reason string or a share sheet is not the password Autofill list the OS hosts.

Build an Autofill-extension string inventory

Localize the Credential Provider extension and AutofillService as their own bundles: host vault String Catalog membership does not paint OS-hosted fill lists, generate-password chrome, or dataset presentations.

For each Autofill-facing string, record:

Put list actions, empty states, generate-password labels, and configuration copy in the extension catalog with translator notes that the string appears in a compact OS-hosted panel and must stay short. Do not assume a shared host catalog is enough. Xcode target membership and Android res/values-*/ packages for the Autofill module are part of the localization contract.

Keep a separate inventory for Settings-visible names. On iOS that includes how your product name appears under Passwords options and any configuration interface you show when AutoFill is enabled. On Android it includes the Autofill service label users see when picking a provider.

Configure Settings enablement separately from vault translations

Treat Settings enablement and configuration UI as a first-class localization surface, and re-verify after device language changes because scheme language alone does not prove the extension resolves the right .lproj.

Apple's ASCredentialProviderViewController documentation describes an optional configuration interface you can show when people first enable your credentials manager in Settings. That UI runs in the extension process. A vault that looks German in the container can still open an English configuration screen if the extension target never received the German catalog.

Use that surface for these jobs:

1. Explain why AutoFill needs your extension and what data stays on device, in the user's language.
2. Offer first-run unlock or vault-selection copy without forcing an English host launch.
3. Keep error and permission strings in the same reviewed catalog as the credential list.
4. Never treat a translated App Store listing or vault onboarding as proof that Settings enablement is localized.

QA must change Language and Region on the device or simulator, not only the Xcode scheme Application Language. Open Settings → Passwords (or Autofill services on Android), enable your manager, and confirm every system-presented string before you call the Autofill surface done.

On Android, follow the AutofillService fill workflow: the system binds your service after explicit enablement, calls onFillRequest, and expects a FillResponse of Dataset objects. Presentation strings in those datasets must resolve from localized resources in the service package.

Own host-versus-extension catalog boundaries

Shared code is useful. Shared assumptions are not. If a Swift package or Android module supplies Autofill captions, confirm the Credential Provider or AutofillService process can load those resources at runtime. A string that resolves in the vault's unit tests can still be missing when the extension runs in a tighter sandbox.

Practical rules:

1. Give the Credential Provider extension its own String Catalog or .lproj tree, even when keys mirror the host.
2. If you share a framework, enable the localization resources for the extension target and verify loading with the extension scheme.
3. Keep English base strings complete so missing translations fail loudly in pseudo-localization rather than silently falling back in production.
4. Document which strings are suggestion identity metadata versus UI chrome so translators do not "translate" a relying-party identifier.

ASPasswordCredentialIdentity describes identities you can register for the suggestions list. User-facing labels attached to those identities still need a deliberate language policy when the vault supports an in-app language that differs from the device language.

Inventory Android dataset presentations for expansion

Inventory Android Dataset RemoteViews presentation layouts for text expansion: a translated action label can truncate or block other controls in the system Autofill UI even when the vault app looks fine.

Android's Dataset documentation describes groups of fields used to autofill parts of a screen and points services to presentation UI for what the system shows. Those presentations are often compact rows above the keyboard. German, French, and Finnish action labels expand. The Proton Pass Autofill report above is a concrete reminder that a translated button can break the entire fill sheet.

Practical rules for presentations:

1. Keep presentation layouts in the AutofillService module with values-* string resources, not hardcoded English in layout XML.
2. Design for expansion: prefer shorter verbs, allow two-line titles where the OS permits, and avoid adjacent icon-only hit targets that disappear when a label grows.
3. Pseudo-localize presentation layouts in CI with long placeholders before you ship a new locale.
4. Manually open Autofill on a device language that expands (German is a reliable stress test) and confirm Cancel, Create, and Fill actions remain tappable.

iOS Autofill panels have the same risk. Compact navigation bars and bottom actions need the same short-string discipline and device-language QA.

Verify Autofill the way users enable it

Release checks should exercise the Credential Provider and AutofillService as system surfaces, not only as preview controllers inside the vault.

Minimum verification matrix:

Automate what you can inside the extension and service test targets, then keep a short manual pass on a physical device because Settings paths and Autofill selection UI differ across OS versions.

Release workflow checklist

1. Inventory extension credential-list, generate-password, empty-state, and Settings configuration strings separately from vault marketing UI.
2. Confirm extension and AutofillService target membership for every catalog or values-* package the fill UI loads.
3. Localize Android dataset presentation layouts as first-class Autofill strings.
4. Run pseudo-localization on the Credential Provider scheme and AutofillService package.
5. Verify Language & Region changes on simulator and one physical device per major OS, including Settings enablement.
6. Stress-test at least one expanding locale for truncated or blocking actions in the OS-hosted panel.
7. Block release if the vault is translated but Autofill still shows English chrome or unusable translated controls.

How i18nAgent helps

Once extension and presentation strings live in normal resource catalogs, they can move through the same translation workflow as the rest of the app. i18nAgent helps teams keep iOS and Android resource files in sync, review AI drafts with human auditability, and catch formatting issues before a password-manager release. Pair that pipeline with the Autofill-specific checks above so polish in the vault is not mistaken for a finished fill experience.

Key takeaways

• Credential Provider and AutofillService fill chrome are extension-owned, not host-catalog side effects.
• Localize Settings enablement and configuration UI, then verify with device Language & Region changes.
• Inventory Android dataset RemoteViews presentations for text expansion so translated actions stay usable.
• Gate release on extension-scheme and physical-device Autofill checks, not only on a translated vault app.