Salesforce Translation Workbench is useful when a CRM organisation needs field labels, custom labels, picklist choices and help text to make sense to users in different languages. People searching Salesforce Translation Workbench, how to translate custom labels in Salesforce, Salesforce picklist translations, or why a Salesforce translation is not showing usually want an operational answer: make the right text appear for the right language without changing the field, value or automation beneath it. The visible label is one layer; the record and workflow are another.
A salesperson might see “Qualified”, “In progress” or “Closed” as a picklist label. A custom Lightning page might show “Submit for approval”. A case field might have help text that controls how staff record an escalation. Translating these words is not harmless decoration. A misleading target can tell someone that a case is closed when it is still pending, or suggest that pressing a button merely saves a draft when it actually launches approval. Reliable speed comes from verifying the underlying Salesforce component and its behaviour before selecting target wording.
This guide focuses on one reader job: prepare, enter and validate multilingual translations for eligible Salesforce metadata through Translation Workbench and related custom-label surfaces, while preserving API names, record values, permission boundaries and business meaning. It does not explain general machine translation, translate customer-authored free text, or change the organisation’s data model. Instead it follows a fictional service team’s release through configuration, term decisions, testing and troubleshooting, with checks an administrator and translator can use together.
Quick answer: localise what users see and leave system identities alone
Begin in a safe Salesforce environment with a known org configuration. Confirm Translation Workbench availability, the target language setup, the user’s language selection and the permissions required for editing the chosen component. Inventory the custom labels, field labels, help text and picklist display values included in the release. Translate each against its business context. Enter translations through the supported interface, then sign in as appropriate test users and inspect the actual Lightning screens, records and flows. Confirm that API names, stored picklist identities, formulas, triggers and validation rules still operate as before.
Avoid using one English label as the primary key of your translation project. Salesforce contains components with names and identifiers distinct from their display text. Two fields can display “Status” but have different object ownership and different meanings. A global value set can supply options across several fields. A custom label can be referenced from a Lightning component or an expression. The place where the text is authored determines how it is translated and how broadly the result appears.
A useful acceptance statement sounds like this: “French-language support agents see the translated case-priority labels and escalation button in the customer-service workspace; a case marked with the High priority value remains High in reporting and automation.” The sentence defines audience, component, scope and behaviour. It is easier to verify than “make Salesforce French”. A fast review is one that knows in advance what must change and what must not.
Understand four different kinds of language in a CRM screen
First is Salesforce’s own standard user-interface language: menus, common controls and platform text supplied according to supported language settings and product capabilities. Second is organisation metadata: custom object and field labels, help text, picklist display labels, custom labels and other supported configuration text. Third is authored content: descriptions, customer messages, articles, emails, document bodies and records. Fourth is generated output: the result of formulas, Lightning components, flows, templates or integrations that may combine labels with live data.
Translation Workbench operates on supported metadata categories. It is not a universal engine that translates any text stored in a Salesforce record or any phrase rendered by external code. A customer may enter an English complaint description; changing the case field label to Spanish does not translate the complaint. An agent may see a translated picklist caption but an integration can still receive the original stable value. A Lightning custom component that hard-codes a phrase may not pick up a translation until its developer routes that text through an appropriate localisable resource.
Separating these layers prevents a common false diagnosis. A tester sees one English phrase and declares “Translation Workbench failed”. The phrase might be platform text unsupported in the target locale, a label never translated, a record value, or text assembled by custom code. Each has different ownership. First ask, “What generated this particular string?” Then ask, “Which mechanism should supply its translation?” Only after those two answers should a translator edit text.
The business identity behind a picklist label
Consider a service organisation whose cases have a priority picklist with options Low, Medium and High. The displayed options can be translated into a support agent’s language so the form reads naturally. The underlying stored choice and the automation built around it should continue to represent the same category. Salesforce documents distinctions between user-facing labels and API-oriented values; treating them as the same thing can lead to dangerous workarounds.
Suppose a well-meaning team changes an API value because it wants the label to read differently in another language. Reports, integrations, formulas, import mappings or validation logic may reference that internal identity. A translation request is not permission to change such contracts. Translate the displayed label using the supported metadata translation feature; keep system identities under the data-model owner’s change process. If a source label itself is misleading, improve it through a reviewed metadata change and then update target translations against the new source.
A useful translation worksheet has separate columns for object or value-set owner, component identity, source display label, approved target display label, user-facing meaning and whether the value participates in automation. The last column does not grant the translator access to code; it warns the reviewer that the wording is consequential. The system can preserve an option’s stored identity while displaying a grammatical form suited to the target language. That is the foundation of safe CRM localisation.
Set up a controlled multilingual test, not a guessing session
Before entering translations, confirm the org and Salesforce edition or feature surface you are working with. Enable Translation Workbench and add supported languages through current Setup instructions, according to permissions and release-specific capabilities. Assign translator access appropriately. A system administrator should not grant broad permissions merely because a translator needs to edit one set of labels; use the access model supported by your organisation and the platform. Keep a note of the configuration used for testing.
Prepare at least two synthetic test users whose language preferences differ. Their user locale and language settings may affect different aspects of presentation, so record both rather than assuming the browser’s language switch proves what Salesforce selected. Put them in appropriate permission sets and profiles for the page under test. One test user may be able to edit a case while another can only view it. The localisation check should not accidentally bypass that distinction by testing exclusively as an administrator.
Use a sandbox or comparable non-production environment for the initial release. Build dummy accounts, contacts and cases with no real customer information. Record the target Lightning app, object, page layout or component and the version of any managed package involved. If a label belongs to a vendor package, translation and override options can differ from labels your team owns. A narrow test fixture makes it possible to investigate a missing translated value without disturbing live CRM records.
Discover the source component before writing a target phrase
A Salesforce page can contain several textual surfaces in close proximity: section headings, custom field labels, custom button captions, values from a picklist, related-list titles, custom labels used inside Lightning components, and data entered by users. Their translation editors and change histories are not necessarily the same. Start with the visible screen, identify the object and element, and determine the actual metadata owner. Do not assume the first matching “Status” returned by a search is the one that appears in your case workspace.
For example, a service agent sees “Reason” beside a dropdown. The dropdown might belong to a case field, a custom object, a flow screen or a component-specific control. If you translate the Case Reason label but the active flow uses a custom screen choice label, the screen will remain English. Conversely, changing a global picklist label might affect more screens than the immediate requester anticipated. Search broadly enough to discover ownership, then narrow the edit to the intended component.
Request context from the product owner. What question is the field asking? What decisions depend on the value? Does “Reason” mean reason for a complaint, reason for return, reason for closure or a staff member’s internal justification? The same English noun may need distinct target phrasing. The fastest useful question is often about business process rather than language. A translator who understands the work makes fewer corrections later.
Custom labels: a stable resource for reusable interface phrases
Salesforce custom labels provide reusable text that code and page components can reference, with translations supported for enabled languages. They are appropriate for phrases such as a button caption or message intended to appear in multiple places. Salesforce documentation describes accessing custom labels through Setup and maintaining their translations. The label’s technical identity is not the same as its displayed value. A translation should change the user-facing message without renaming references used by application logic.
Imagine a custom Lightning component displaying “Request supervisor review”. Its developer uses a custom label instead of hard-coding the English phrase. The localisation reviewer can add a target-language equivalent without modifying the component source just to change words. However, the target must still express the action precisely. Does clicking request review, initiate an approval process immediately, or notify a supervisor but leave the case open? A label cannot be translated responsibly without knowing which behaviour the component implements.
If the label comes from a managed package, confirm the documented override path and limits. Your org may be allowed to add or override translations but not edit or delete the package’s underlying source label. Do not work around a restriction by copying arbitrary vendor metadata or renaming code references. The correct route may be to use the supported translation override or ask the package vendor for clarification. Ownership matters just as much as linguistic quality.
Worked case: translating a case-priority picklist for French users
Our fictional customer-service company operates in English and French. In the English workspace, the Case Priority field offers Low, Medium and High. French agents need labels that read naturally and distinguish urgency reliably. The language lead proposes equivalents and the support operations manager confirms what each priority means under internal service rules. The translator does not invent an SLA or response deadline: if “High” means a particular response window, that is a policy definition, not an automatic property of the word.
The administrator identifies whether this field uses an object-specific picklist or a shared/global value set, locates the supported translation surface, and enters the three target labels. They leave stable API values intact. In a sandbox, two dummy cases are created with different priorities. French and English test users open the same records. Each sees appropriate display language according to the org’s settings, while reports and automation still categorise the cases consistently.
The team tests changes as well as displays. A French agent changes a dummy case from Medium to High, saves it, and a supervisor checks the resulting record and any configured notification. The change must reflect the same business state as an English agent’s action. Next, they inspect filters and list views; a translated choice should not become a second data category. Finally, they validate that the target wording does not make High sound like “closed” or “approved”. This is a translation test and a CRM integrity test in one.
Worked case: translating a button that starts an approval action
A Lightning record page uses the custom label “Submit for approval”. An enthusiastic draft target reads like “Send to supervisor”. The latter may be a tempting shorthand, but the real process could submit into a formal approval flow with multiple approvers rather than send a message to one person. The operations owner explains what clicking does: locks or routes parts of the record, starts an approval request, and changes relevant workflow state according to configuration. The translator must not promise an ordinary chat notification when the button performs something more consequential.
The team then checks the entire micro-journey. What does the button say before the click? Is there a confirmation dialog? What status appears afterwards? How does the user withdraw or recall the request, if that option exists? The target wording should preserve distinctions between submission, approval, rejection and notification. Translating these steps independently can produce a contradictory interface: a button says “Approved” while the result says “Awaiting approval”. A state map reveals this before release.
For the test, use a synthetic record whose approval route is safe to exercise. Verify that the French and English users reach equivalent state transitions and that no target text was mistaken for a technical workflow variable. If the source button is misleading even in English, request a source-label correction before finalising translations. The translation team is not responsible for redefining the approval process by rewriting its caption.
Field help text requires more explanation than a field label
A label such as “Escalation reason” identifies a field; help text might explain when staff must complete it. Short UI fragments often tempt reviewers to compress too aggressively in target languages, especially on crowded forms. But the explanatory text may contain conditions, exceptions or references to a policy. Removing one clause to make the sentence fit a tooltip can change how staff complete required data. The goal is clear behaviour, not minimal characters at any cost.
Suppose the help text says, “Complete this field only when the case has been escalated to the regional support team.” A target that says “Complete for all urgent cases” changes both the trigger and the responsible team. The reviewer should identify the condition and its scope before translating. Ask whether “regional support team” is a defined organisational unit that should retain a particular name or official translation. Do not replace it with “manager” merely because that word is more familiar.
Test the help text where it appears. The full sentence may be available in a tooltip, an accessible description or a screen-reader announcement. A shortened label does not prove the longer help text was entered or loaded correctly. If it overflows, report the component’s display constraint. Salesforce metadata translation can supply the correct wording, but page layout and accessibility are additional responsibilities. A translation release should cover both what people see and what assistive technology exposes.
Language selection is not the same as browser geography
A tester located in Singapore opens a Salesforce page while their browser is configured to French and expects every label to change. That is not an adequate Salesforce language test. The user’s language setting, the org’s enabled languages and the specific product feature influence what can display. Regional locale preferences can affect formatting conventions independently of the language chosen for interface text. Record the actual user language rather than inferring it from IP address, browser defaults or operating-system settings.
Use one known target-language test user and one known English user. Reopen the same object, record and component with equivalent permissions. This comparison helps separate missing translations from missing access. If the French user sees an English phrase, inspect whether that component was translated and whether its translation is supported and active. If both users see the new French value, investigate whether a source label was overwritten globally instead of translated per language. That can happen when someone changes the default label, thinking they are adding a translation.
The acceptance goal is not that every piece of CRM content follows the interface language. User-authored descriptions may remain as written; customer-entered data should not be silently transformed. The goal is that eligible metadata labels display according to configured language settings and continue to represent the same fields and actions. A multilingual organisation needs clear expectations about which surfaces are localised and which are original record data.
Labels, values, API names and automations: draw the boundary visibly
Translation Workbench changes the language presentation of supported metadata. It should not be used as a shortcut to change system identifiers. A field’s API name, the internal identity of a picklist option, a flow variable, an object reference and a formula’s meaning belong to technical configuration. They are not free-form prose. The fact that a source label and an API value happen to share English words does not make them interchangeable.
Take a custom field with a label “Customer category” and an API name ending in __c. A French label may communicate the concept clearly; the API name remains under the system owner. Integrations and queries can reference that technical name. Changing it to look French is a schema modification with broader consequences, not a translation. Similarly, a picklist may show translated labels while automation must continue to work against the intended stored values.
Make this separation explicit in the team’s handoff. The translator may suggest that a default English label is unclear. The administrator can then ask whether it is safe to revise the source display label. The developer or CRM architect evaluates API, integration and automation effects. Only after that decision should target translations be aligned. Dividing responsibilities does not slow a good team down; it prevents small language changes from becoming unplanned software releases.
Global value sets and the unexpected blast radius
A global value set is useful when several picklist fields share a standard set of allowed choices. It can also create scope risk during localisation. A translator sees one field in a service case and requests a new target label for “Pending”. The same value set may be used on another object where “Pending” has a different surrounding explanation. Even if the underlying status concept is intended to be consistent, the word’s apparent meaning on one screen may differ from another team’s expectations.
Before translating or renaming a shared set, list its consumers. Consult the business owners of the main workflows and decide whether the target label supports all of them. A single consistent concept is valuable; a forced shared word that confuses one department is not. If the application architecture has combined conceptually different statuses into one value set, localisation may expose a design problem. Do not solve that problem by silently altering an API value or making one translation deliberately vague.
Test at least two consuming fields. In a sandbox, select the target label on one record and check how it appears on another relevant page and in reports. Confirm that data filters still group records by intended values, not by translated display strings. When shared metadata is involved, a translation change can be low risk technically and high impact semantically. Document the intended scope before release so a support team can tell whether a different label was an expected outcome.
Managed packages: translation rights have boundaries
Salesforce organisations often install managed packages that provide their own metadata and interface components. Those packages are owned and updated by vendors. Some surfaces allow translation or label overrides; others may be protected or require a vendor-managed localisation process. The correct action depends on the package feature and Salesforce’s supported mechanism. Do not assume that an administrator can change every caption appearing on a managed component just because Translation Workbench is enabled.
Suppose a vendor appointment package displays “Check in”. Your team prefers a local equivalent closer to “Register arrival”. First identify whether the phrase is a Salesforce custom label, a packaged picklist value, a component-local resource or embedded text. Check the vendor’s documentation or supported override surface. If an override is allowed, translate with a real appointment workflow in view. If the label is not exposed, record a product request to the vendor rather than editing a packaged file in an unsupported way.
After a managed-package update, recheck customised translations. A vendor may add new strings, change source wording or alter an action’s meaning. A former target may remain visible but become semantically stale. Keep a package-version column in the localisation register. Version awareness matters more than a promise that any particular Salesforce feature behaves identically across every managed package and release.
Custom Lightning components can fail outside Translation Workbench
A Salesforce page may mix standard fields with custom Lightning Web Components or other programmed UI. If a component is using a custom label correctly, its translation can follow the supported label resource. If a developer placed the English phrase directly inside the component, Translation Workbench may not have a separate entry to edit. The absence of that entry is a development boundary rather than proof the translator did something wrong. Raise an engineering task to expose the message through an appropriate localisable mechanism.
Consider a custom component that prints “You have {count} open items.” The whole message needs language-aware treatment because target languages differ in word order and plural rules. A developer who concatenates “You have ”, the number and “ open items” offers translators fragments without enough grammar. The team should design a complete message or an appropriate resource pattern supported by the component stack, then test representative values. The translator should not rewrite the JavaScript expression to make the words fit.
Inspect both static labels and dynamic states. A panel may translate its heading yet retain an English empty-state message, loading error or permission denial. These less common branches are often missed because testers open only a populated record. Use a synthetic dataset that can trigger zero results, one result, several results and an access-denied state. Translation quality is measured by what the user encounters across conditions, not by one ideal screenshot.
A high-stakes distinction: language must not create a promise
In customer service, target text can carry promises about response times, refunds, eligibility or authority. A short source label may already be ambiguous. Translating “Resolved” as “Closed permanently” can overstate the state of a case if it may later reopen. Translating “Eligible” as “Approved” may suggest a decision has been made when it only means a preliminary criterion is met. Translating “Priority” as “Guaranteed response” invents a service commitment. These are not merely stylistic mistakes.
For each consequential label, write a truth statement: what exactly is true of the record when this value is selected? Which next step is permitted? Does the state trigger an external notification or a customer-facing email? Ask the process owner to confirm the statement. A translation that expresses the truth in natural language is better than an elegant phrase that suggests the wrong workflow. If the process itself cannot be described consistently, the defect may be in the metadata design rather than the translation.
Do not rely on a single bilingual staff member to approve legal or regulated wording if organisational policy requires specialist review. This article is an operational language guide, not regulatory advice. The general rule is to escalate high-impact semantics to the people accountable for them. Clear ownership protects customers and translators alike: language editors should not be asked to make policy decisions disguised as vocabulary choices.
Testing a translated picklist from selection to reporting
A screenshot of French options is useful, but it is only the first test. Select each option in a dummy record and save. Confirm that the expected field value persists, that required field conditions still work, and that validation messages remain intelligible. Open the same record as an English user and confirm the underlying state corresponds to the selected target option. Next, inspect a report or list filter whose results depend on those values. The grouping should reflect the same business categories across user languages.
For a global value set, repeat the exercise on a second consuming field. For a custom Lightning form, test a submission with valid and invalid data. For an approval label, trigger the process in a sandbox and verify its state. Record whether the user saw the right words, selected the right option, and obtained the intended result. A check that focuses only on visible text can miss misalignment between label and action.
Compare the target with the source language side by side, but avoid forcing identical word order or length. The purpose is semantic equivalence and functional clarity. A target may need a longer phrase to distinguish “Draft” from “Pending approval”. If a control clips it, report layout separately. The CRM should adapt to the language where feasible, rather than making a business action ambiguous to fit a design inherited from a shorter English word.
Troubleshooting: the translation is saved but the page is still English
Start by identifying the component. Is the text a field label, custom label, picklist value, custom component string, managed package resource or record data? Confirm that the relevant translation was entered for the intended supported language. Then check the test user’s language selection and the page being opened. If a translation was entered for one component but the screen uses another, the apparent failure is an ownership mismatch. If a label was edited in the source language instead of a target translation, both users may see the same changed wording.
Next examine deployment and environment. Was the translation applied in the sandbox while the tester opened production? Did metadata move between orgs through a deployment package or release process? Are there differences in component versions or permissions? Does the screen render through a custom Lightning component that is not using the translated resource? Avoid repeatedly saving the target text before checking those facts. One wrong assumption about environment can make ten perfectly good edits appear ineffective.
Finally, reproduce a specific record and role. A system administrator may see a layout or field unavailable to an ordinary agent. An Experience Cloud page may render different components from an internal Lightning app. A translation is not validated just because it looks correct in Setup. Confirm the real audience’s view. Record the symptom and cause, then decide whether the fix belongs to translation, metadata configuration, code or access rights.
What automation can test, and what still needs a human
Automated deployment and test tooling can compare metadata identities, check whether expected labels and translations are present, and exercise workflows against known values. Such tools can catch missing files, unsupported references or unexpected changes to configured objects. A regression suite can create a synthetic case, set its priority and assert that the underlying data state is correct. This protects the technical boundary that translators should not cross.
An automated assertion that a button exists does not prove the target label makes its consequences clear. A machine can compare “Approved” with a glossary, but may not know that the current workflow stage is only “Submitted”. Human review must connect the words to a business process and audience. Make the reviewer walk the same route as the user: read the current record, choose an action, observe the confirmation, and interpret the result. High-impact changes should include both technical and semantic evidence.
Do not turn every translation into a giant manual test matrix. Choose representative cases by risk. A custom label for a decorative section heading needs a rendering check. A global approval-state value needs role, state, report and automation checks. Proportional testing is how large multilingual teams remain efficient while catching the errors that matter most.
A release register that lets the next administrator understand the choices
For each translated item, record the Salesforce component type, owning object or package, stable identifier, source display text, target language, target display text, meaning note, reviewer, environment and tested route. For a picklist, note whether a global value set is involved. For a custom label, record where it is referenced and whether it comes from a managed package. Add the date and version of the approved release, but do not imply that a later Salesforce upgrade will automatically preserve all semantics.
The register should distinguish translation changes from source-label changes. If the English default is revised, target languages may need review even when their stored translations do not disappear. If a status option is retired, do not leave a target label in documentation as though it is still selectable. If a new custom field is added, mark it as uncovered until tested. These small maintenance habits help the organisation avoid a mixture of current and historical labels in different languages.
Keep evidence lightweight. A screenshot with dummy data, a test-user description and a checked outcome is more useful than a huge folder of indistinguishable images. An administrator taking over the project should be able to answer: What is the key, why did we choose these words, where does it appear, and what must be retested after an update? That is the practical definition of a maintainable translation decision.
A training exercise: change the label, not the business state
In a sandbox, create an example picklist value with a harmless status such as “Waiting for review”. Record its API-oriented identity separately from its displayed English wording. Enable an appropriate target language and provide a reviewed target display label. Sign in as a test user with that language and create a dummy record using the option. Then reopen the record as an English user. Compare visible labels and stored identity under the supported inspection tools.
Ask participants to identify what changed and what did not. Did the display phrase change per language? Did the selection still represent the same status? Did any report grouping change? Was the target phrase natural in the sentence around it? Next, repeat with a custom label referenced by a simple Lightning component. Deliberately leave one empty-state message untranslated so reviewers practise tracing ownership rather than guessing at the entire page.
Finally, offer two competing translations for an approval button and ask the group which one is safer. Do not vote on sound alone. Open the action, read its confirmation, inspect the resulting state and decide which phrase describes the truth. This exercise teaches the most transferable skill: translate the user’s understanding while preserving the system’s meaning and technical identity.
Transfer: a useful general rule for multilingual enterprise software
Enterprise applications contain stable machine identities beneath adaptable human labels. Salesforce makes that separation especially visible through metadata, custom labels, picklists and system APIs. It explains why a phrase can be translated without changing record values, and why an apparently minor wording request can require a business owner’s approval. The underlying pattern applies to other CRMs, ERPs and workflow systems, though each has its own technical translation features and permissions.
The most efficient workflow is therefore not to translate every piece of text in sight. It is to identify ownership, confirm the business truth, change only the supported display value, and test the actual audience’s actions. That model prevents two costly forms of drift: a linguistic drift in which target words misstate a process, and a technical drift in which someone alters identifiers to satisfy a display requirement. Both are avoidable when the decision is scoped correctly.
For neighbouring methods, eduKateSG’s placeholder and non-translatable handling covers protection of variables and identifiers; localisation build validation covers technical release gates; and look-ahead reading explores context before committing target wording. Those pages own general techniques. Here the dominant job is preserving Salesforce CRM semantics while entering and validating supported metadata translations.
Frequently asked questions
What can Salesforce Translation Workbench translate?
It supports translations for eligible Salesforce metadata, including categories such as field labels, picklist labels, help text and other supported configuration surfaces depending on product features and release. Custom labels have their own supported translation pathway. It is not a universal translator for every customer record or piece of text in custom code. Identify the component before editing.
How do I translate Salesforce custom labels?
Find the custom label in Setup, check whether it is owned by your org or a managed package, and use its supported translations or override interface for the target language. Test the component that references the label. A saved target value does not prove the component uses that resource or that the target accurately describes its action.
Does translating a picklist value change the data stored in records?
A supported label translation should change the human-facing presentation rather than redefine the stable value or API identity. Confirm this in your own metadata configuration and test a saved dummy record, report and automation. Do not rename technical values as an informal translation workaround.
Why does my user still see English labels?
Check enabled target languages, the user’s language setting, the specific metadata owner and whether the translation was entered for the correct component. Also check if the phrase is custom code or record content rather than supported metadata, and whether the test is being run in the environment where translations were deployed.
Are custom labels and field labels the same thing?
No. A custom label is a reusable resource referenced from code or page expressions. A field label is metadata describing a field on an object. Both can carry human-facing wording, but they have different identifiers, usage contexts and translation workflows. Translate the surface that actually owns the phrase.
Can I translate a label belonging to a managed package?
Some packaged components permit translations or overrides through supported interfaces, while other metadata remains controlled by the vendor. Check package documentation and Salesforce’s allowed translation surface. Do not bypass a protected component by editing underlying references without vendor or platform guidance.
Will a translated picklist label appear the same on every screen?
Not necessarily. A field may use a global value set or a component may render its own separate label. Confirm the actual field or metadata owner and test major consumers. Do not assume an edit made on one screen guarantees a translation in every Lightning component, flow or external app.
Should “Submitted” and “Approved” use similar wording?
Only to the extent that they truly represent related workflow states. They are not equivalent. A submitted record may await a decision. The target language should preserve that distinction, even if one longer phrase is needed for clarity.
How do I check a translation without changing real customer cases?
Use a sandbox and synthetic test users and records. Exercise representative selections, validations, approval states and reports. Compare target- and source-language views with equivalent permissions, and remove the fixtures after testing according to team practice.
What is the best way to maintain Salesforce translations over time?
Keep a register of component identity, source and target labels, business meaning, owner, test route and package or release context. Review affected translations when a workflow, field or vendor package changes. A translation can remain technically stored while its business meaning becomes outdated.
Summary: preserve the CRM while translating its interface
Salesforce translation QA begins with metadata identity. Locate the exact custom label, field, help text or picklist value; confirm its business meaning; enter a target-language value through the supported surface; and test the real user journey. Protect API names, stored values and automation from unapproved edits. Use fictional records, compare language settings explicitly, and review consequential actions with their owners. The goal is a multilingual CRM in which words change appropriately while business truth stays intact.
Official references and product documentation
Consult Salesforce’s Considerations for Managing Translations, Custom Labels translation and override guidance, and its documentation for translated custom labels on Lightning pages. Salesforce capabilities and labels evolve across releases and product editions; confirm the applicable Setup options and language support in the org being tested. The service-company examples here are fictional teaching scenarios.