11.3 Multilingual Localization, Custom Labels & Translation Workbench

11.3 Multilingual Localization, Custom Labels & Translation Workbench

Exam Focus: In government IT implementations, multilingual localization is not merely an optional user experience enhancement—it is a statutory civil rights mandate. On the AP-222 exam, candidates must understand legal compliance frameworks (Title VI, Executive Order 13166, Limited English Proficiency), configure multi-language settings in Experience Cloud, translate platform metadata via the Translation Workbench, localize OmniStudio assets (OmniScripts and FlexCards) using Salesforce Custom Labels, and manage multi-currency conversions for international regulatory and grant operations.

---

Statutory Mandates for Multilingual Public Administration

Unlike private commercial enterprises that can elect to target a single language demographic, public sector agencies are legally obligated to serve the entirety of their constituent populations. In the United States and globally, strict legal standards govern digital language accessibility:

• Title VI of the Civil Rights Act of 1964: Prohibits discrimination on the basis of race, color, or national origin in any program or activity receiving federal financial assistance. The U.S. Supreme Court has established that failing to provide language assistance to individuals with Limited English Proficiency (LEP) constitutes national origin discrimination.
• Executive Order 13166 ("Improving Access to Services for Persons with Limited English Proficiency"): Directs every federal agency, as well as state and municipal entities administering federally funded block grants or programs (such as Medicaid, SNAP, and HUD housing), to develop and implement comprehensive language access plans.
• The Department of Justice (DOJ) Four-Factor Analysis: Agencies evaluate their language translation obligations based on four statutory criteria:
  1. The number or proportion of LEP individuals eligible to be served in the jurisdiction;
  2. The frequency with which LEP individuals come into contact with the agency's programs;
  3. The nature and importance of the statutory service (e.g., emergency crisis assistance and food support carry higher urgency than recreational boating permits); and
  4. The resources available to the agency and the cost of translation services.
• State and Local Mandates: Stringent state statutes—such as the California Dymally-Alatorre Bilingual Services Act and New York City Local Law 30—mandate that public agencies provide vital digital documents and intake workflows in designated threshold languages (often 10 or more languages, including Spanish, Traditional Chinese, Vietnamese, Russian, Arabic, Haitian Creole, Korean, and Tagalog).

Failure to deploy fully localized digital self-service portals exposes public agencies to civil rights compliance investigations, administrative consent decrees, and federal funding revocations.

---

Experience Cloud Multi-Language Architecture & Site Localization

Salesforce Experience Cloud provides a robust, native multi-language runtime framework. Configuring an Experience Cloud site for multilingual constituent delivery involves three foundational architectural steps in Experience Builder.

+-----------------------------------------------------------------------------------+
| Experience Cloud Multi-Language Architecture                                      |
+-----------------------------------------------------------------------------------+
| [1. Language Configuration in Experience Builder]                                 |
|     - Set Primary Language: English (en_US)                                       |
|     - Add Supported Languages: Spanish (es), Chinese Traditional (zh_TW), etc.     |
+-----------------------------------------------------------------------------------+
                                        |
                                        v
+-----------------------------------------------------------------------------------+
| [2. Language Selector Component & Locale Resolution]                              |
|     - Constituent selects language via header Language Selector component         |
|     - Runtime sets session locale, cookie, and URL parameter (?language=es)      |
+-----------------------------------------------------------------------------------+
                                        |
                                        v
+-----------------------------------------------------------------------------------+
| [3. Content Translation & Asset Rendering]                                        |
|     - Page Content: Experience Builder Multilingual Translation (XLIFF .xlf)     |
|     - Metadata: Translation Workbench (Fields, Picklists, Validation Errors)      |
|     - UI Forms: OmniStudio Multi-Language Engine ($Label Custom Labels)           |
+-----------------------------------------------------------------------------------+

1. Language Settings in Experience Builder

Administrators configure languages directly within the Settings -> Languages panel of Experience Builder:

• Primary (Default) Language: The baseline language in which the site is authored (e.g., English (US)). If content is missing a translation in a secondary language, the runtime gracefully falls back to this primary language.
• Supported Languages: The secondary languages activated for the site. When an administrator adds a language (e.g., Spanish, Vietnamese), Experience Cloud exposes translation hooks for all pages and components.

2. The Language Selector Component

To allow constituents to switch languages dynamically:

• Placement: The out-of-the-box Language Selector component is placed in the global header or footer of the site theme layout, ensuring persistent availability across all pages.
• Locale Resolution Order: When a constituent accesses the portal, the platform resolves language in the following hierarchy:
  1. Explicit language URL parameter (e.g., ?language=es);
  2. Constituent's authenticated user profile language (User.LanguageLocaleKey);
  3. Persistent language cookie set during a prior visit;
  4. Constituent's web browser language header (Accept-Language); and
  5. The site's default primary language.

3. Experience Builder Content Translation & XLIFF Workflows

For static site content (page titles, rich text blocks, header links, navigation menus):

• Inline Translation: In Experience Builder, toggling the language dropdown in the top canvas toolbar allows administrators to edit and enter translated text directly for each component.
• XLIFF Bulk Export/Import: For professional translation workflows, Experience Cloud supports exporting all site content into standard XLIFF (.xlf) XML files. Translation agencies populate the target language tags, and administrators import the completed .xlf file back into Experience Builder, instantly localizing hundreds of pages without manual data entry.

---

Translation Workbench Configuration & Metadata Localization

While Experience Builder manages visual presentation content, Salesforce platform data structures—custom field labels, picklist values, help text, and system validation messages—are translated using the Translation Workbench in Salesforce Setup.

Enabling and Managing the Translation Workbench

1. Activation: Navigate to Setup -> Translation Workbench -> Translation Settings and click Enable.
2. Language Configuration: Add supported languages and designate authorized Translators (internal Salesforce users who are granted permission to enter translated strings directly into Setup).

Translatable Metadata Components

Implementation teams must ensure that all public-facing metadata categories are translated across all supported languages:

Translation File Export and Import (.stf & .xlf)

For enterprise public sector deployments with thousands of fields and picklists, manual translation in Setup is impractical. The Translation Workbench provides automated file-based workflows:

• Export Options:
  • Source: Generates a file containing all translatable labels in the primary language.
  • Untranslated: Generates a file containing only labels that currently lack translations in target languages.
  • Bilingual: Generates a complete file with source text alongside existing translations, ideal for auditing and editing.
• File Formats:
  • .stf (Salesforce Translation Format): A tab-delimited plain text format easily manipulated in spreadsheet software.
  • .xlf (XML Localization Interchange File Format): An industry-standard XML format supported by enterprise Computer-Assisted Translation (CAT) software.

---

Localizing OmniStudio Assets: OmniScripts & FlexCards

Because OmniStudio serves as the primary digital intake and 360-degree presentation layer in Public Sector Solutions, localizing OmniScripts and FlexCards is essential for full statutory compliance.

1. The Custom Labels Framework ($Label)

Hardcoding English strings inside OmniScript step titles, input labels, or text blocks is a severe architectural anti-pattern. Instead, all user-facing text must be externalized into Salesforce Custom Labels (Setup -> Custom Labels).

• Creating Custom Labels: Create a Custom Label with a descriptive name (e.g., Permit_Intake_Step1_Title), assign the default English text, and define translations for Spanish, Chinese, Vietnamese, etc., directly in the label definition.
• Referencing in OmniScript: Reference the label dynamically using the $Label global variable syntax: $Label.Permit_Intake_Step1_Title.

2. OmniScript Multilingual Setup

To activate runtime localization within an OmniScript:

1. Open the OmniScript Designer and navigate to the Setup tab.
2. Locate the Multi-Language checkbox and toggle it to true (IsMultiLanguage = true).
3. Runtime Language Resolution: At runtime, the compiled OmniScript LWC inspects the constituent's session language code (LanguageCode e.g., es, zh_TW). The runtime automatically queries the Salesforce Custom Label cache and renders all $Label references in the matching language.
4. Dynamic Value Replacement: If a constituent toggles the Experience Cloud Language Selector from English to Spanish mid-session, the OmniScript runtime refreshes its labels dynamically without clearing constituent form input data.

+-------------------------------------------------------------------------+
| OmniScript Designer: Setup Tab                                          |
+-------------------------------------------------------------------------+
| [x] Multi-Language: TRUE                                                |
|                                                                         |
| Canvas Step Element Configuration:                                      |
| Step Label:      $Label.Building_Permit_Step_Identity                   |
| Input Label:     $Label.Applicant_First_Name                            |
| Help Text:       $Label.Help_Text_Legal_Name                            |
+-------------------------------------------------------------------------+
                                    |
                    [Constituent Switches to Spanish]
                                    v
+-------------------------------------------------------------------------+
| Client Browser Runtime (Spanish - es)                                   |
+-------------------------------------------------------------------------+
| Step Label:      Identificación del Solicitante                         |
| Input Label:     Nombre de Pila                                         |
| Help Text:       Ingrese su nombre legal según su identificación oficial|
+-------------------------------------------------------------------------+

3. Localizing Error Messages & Validation Rules

Ensuring constituents receive actionable validation guidance in their native language is a frequent AP-222 exam topic:

• Input Pattern Errors: On input elements (such as Social Security Numbers, Federal EINs, or phone numbers), set the custom error message to a Custom Label (e.g., $Label.Error_Invalid_Phone_Format).
• Set Errors Action: When conditional logic triggers a custom business validation, map the error string to $Label.Statutory_Eligibility_Failure_Msg.
• Messaging Banners: Set dynamic warning and informational banners to reference Custom Labels, preventing hardcoded English text from appearing on localized forms.

4. FlexCard Localization

• Binding Custom Labels: In the FlexCard designer, bind text elements, card headers, and button labels to Custom Labels using the {Label.LabelName} merge syntax.
• Localized Formatting: FlexCards automatically format dates, numbers, and currency values according to the constituent's active user locale (e.g., displaying 1.000,50 € for European locales vs. $1,000.50 for US locales).

---

Multi-Currency & Internationalization in Public Administration

While municipal agencies typically operate exclusively in a single domestic currency, state and national agencies frequently handle cross-border commerce, international trade licensing, and multi-national research grants.

Multi-Currency Mechanics in Public Sector Solutions

• Corporate Currency: When Multi-Currency is activated in Salesforce (Setup -> Company Information -> Currency Setup), the agency designates a primary Corporate Currency (e.g., USD). All financial rollups, budget reporting, and executive dashboards calculate against this baseline.
• Constituent Active Currencies: Agencies activate secondary currencies (e.g., CAD, EUR, MXN, GBP). When an international applicant or multinational enterprise files a BusinessLicenseApplication, their fee records (RegulatoryTransactionFee) can be issued and collected in their local currency.
• Advanced Currency Management (Dated Exchange Rates): For long-term grantmaking programs (FundingAward, Disbursement), currency values fluctuate over multi-year grant periods. Enabling Advanced Currency Management allows the agency to establish historical, date-bracketed exchange rates. When a grant disbursement is executed, the platform converts the disbursement amount using the exact statutory exchange rate effective on the disbursement date, preventing accounting distortions caused by currency market volatility.

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: Multi-Language Municipal Business License Intake with Dynamic Error Messaging

A metropolitan city with a 35% Spanish-speaking and 15% Cantonese-speaking constituent population implements an Experience Cloud portal for restaurant and food truck licensing. City legal counsel mandates that all intake steps, statutory disclosure affidavits, input validation errors, and fee summaries must display natively in English, Spanish, or Traditional Chinese based on user selection. A junior developer hardcodes Spanish and Chinese text into separate conditional steps inside three different OmniScripts.

Why is the developer's approach an architectural failure, and what is the standard PSS best practice?

• Flaw in Developer Proposal: Duplicating OmniScripts for each language creates an unmaintainable technical debt crisis. Any future statutory change to form questions or fee logic requires modifying, testing, and deploying three separate OmniScripts in parallel, tripling maintenance costs and risking legal divergence.
• PSS Standard Best Practice: Maintain a single OmniScript. Externalize all step labels, input labels, instructional text blocks, and validation errors into Salesforce Custom Labels. In OmniScript Setup, enable Multi-Language (IsMultiLanguage = true). Deploy the out-of-the-box Language Selector component in Experience Builder. The single OmniScript dynamically renders all labels in English, Spanish, or Traditional Chinese at runtime based on user locale, adhering strictly to declarative platform standards.

Scenario 2: Translation Workbench Export/Import for Large-Scale Regulatory Agency

A state department of agriculture regulates commercial pesticide application and livestock management across 18,000 agricultural enterprises. The legislature passes a mandate requiring the agency's licensing portal to support Spanish and Vietnamese within 90 days. The agency has over 400 custom fields, 60 picklists, and 85 validation rules across its licensing objects. The agency contracts an external certified translation firm that uses SDL Trados software.

How should the Lead Architect orchestrate this translation workflow?

• Activation: Enable Translation Workbench in Setup, add Spanish and Vietnamese as supported languages, and assign administrative translators.
• Export: Perform an export of Bilingual or Untranslated metadata from Translation Workbench, selecting the XLIFF (.xlf) format.
• Translation Execution: Deliver the .xlf files to the translation bureau. The linguists import the files directly into their translation software, populate the translated target strings, and export the completed XLIFF files.
• Import & Verification: Import the translated .xlf files back into Salesforce via Translation Workbench. Review and verify custom field labels, picklist values, and validation error messages in sandbox before deploying to production.