To translate Microsoft Adaptive Cards quickly, you have to protect more than the words visible on a card. A card might ask someone to approve a purchase, enter a name, select a reason, confirm a school appointment or acknowledge a service notice. Under its visible headings and buttons lies a JSON structure that identifies inputs, routes actions and connects a learner or employee’s response to the application. A translation can sound perfect while causing the wrong action, losing a field label or leaving a dynamic message in the source language.
Searches for Adaptive Cards localization, multilingual Adaptive Cards, Copilot Studio card translation, Teams Adaptive Card JSON, translate TextBlock and Action.Submit labels, and JSON/ResX localization often come from people maintaining interactive cards across multiple channels. This guide addresses one specific reader job: translate human-facing card content while preserving the card’s input and action contract. It does not attempt to become a general Microsoft Teams guide, an introduction to bots, or a tutorial on every Adaptive Cards schema version.
The fastest reliable workflow separates the text a person should read from the identifiers and payloads the application must interpret. Microsoft documentation published in 2026 explains that Copilot Studio can export static Adaptive Card text through its localization workflow, while mixed static and dynamic content needs deliberate handling. The general principle holds across implementations even when particular tooling differs: localize the message, preserve the event. See Microsoft’s current Adaptive Cards localization guidance for the platform-specific workflow.
Quick answer: trace the card from wording to submission
Freeze the source card and record the target host, schema version and locale behaviour. Inventory every displayed title, TextBlock, input label, placeholder, validation error, image alternative and action title. Identify hidden or structural fields such as input id, action type, payload keys, routing values and supported version declarations. Translate approved text values with the full dynamic context. Render each locale in the actual host, submit each important action and verify that the receiving application gets the same intended meaning and machine-readable values. Test error, cancel and accessibility paths, not only a successful submit.
This approach saves time by catching defects before they become unexplained workflow failures. If a translated ‘Approve’ button sends the original approve_request value, that may be correct. If the button displays ‘Approve’ but the payload now says reject_request, the problem is critical. The review has to follow the user’s decision through the data flow, not stop at the button’s appearance.
1. Treat the card as a conversation turn with consequences
An Adaptive Card is a structured user interface message. It can contain descriptive text, images, input controls and actions. Depending on the host and schema support, it may collect data or trigger a subsequent application step. When a card asks a question, translation changes the wording of that question; it must not casually change what answering the question does.
Imagine a parent receiving a card in a school communication workflow: ‘Confirm that your child will attend the excursion.’ The buttons say ‘Confirm’ and ‘Unable to attend’. The card may also ask for a contact number. The parent reads a natural-language request, selects an answer and submits data. If the target translation confuses ‘confirm attendance’ with ‘confirm receipt of notice’, the workflow records a commitment the parent did not mean to make.
The central mechanism is intent continuity. The rendered prompt, control labels, selected values, submitted payload and downstream status must remain aligned. A card can be structurally valid and still violate that continuity. Therefore, the owner of this guide is not simply JSON syntax; it is the meaning of interactive multilingual decisions.
2. Establish boundaries before translating
The scope here is card-level language and its interaction with the surrounding workflow. A separate article on Microsoft Teams meeting translation would own transcripts and conversations. A general JSON-localization article would own resource-file syntax. This guide owns the distinctive bridge between rendered Adaptive Card controls and the structured responses they send to an application.
Write a release statement such as: ‘A user reading the card in the target language can understand the same request, provide the same permitted information and trigger the same intended action as a source-language user.’ Then list exclusions: changes to business rules, introducing new approval categories, modifying roles, changing security checks and redesigning the bot flow. Those may be legitimate product work, but they require their own authorization and test scope.
The boundary prevents a translator from being asked to solve a business process problem with language changes alone. A confusing cancellation policy may require a content-owner clarification; a broken submit handler requires developer repair. Localization QA can find both, but it should not silently own every downstream decision.
3. Identify which platform really owns the strings
Adaptive Cards may be authored directly in JSON, generated by code, embedded in a bot, constructed through a designer or used inside Copilot Studio. The correct extraction workflow depends on that source of truth. In Copilot Studio, current Microsoft guidance describes localization export of static card values alongside topic text. For mixed content, the documented Set text variable approach makes the composed string localizable while preserving placeholders. Do not assume another host offers identical export behaviour.
An organization may have a JSON template in source control and a separate localization catalog. Another may generate the card from a server response. Before editing, find the authoritative text: is it a literal TextBlock.text value, a resource key, a server-side formatted message or a value retrieved from a database? Translating the rendered JSON snapshot is wasted effort if it will be regenerated from an English template during the next build.
A ten-minute tracing exercise often saves hours. Pick one visible phrase, find the field that supplied it, and change it safely in a disposable test copy. If the expected card changes, record the mapping. If it does not, stop and locate the real source rather than translating an inactive file.
4. Build a card-string inventory by reader function
Group the card’s strings by how the user encounters them: headline, explanatory text, field labels, placeholders, help text, validation errors, action titles, image descriptions, state announcements and confirmation messages. Give each an internal path or key that remains stable enough for review. Include the associated card or flow ID and the action a user is expected to perform.
For a consent card, record that ‘Contact phone’ is a label for an input rather than a general explanatory sentence. Record that ‘Required’ is an error message shown after a failed submit. Record that ‘Cancel’ may discard the form rather than refuse consent. Those functions determine translation choices. A word-for-word dictionary replacement cannot establish whether the verb should be polite, urgent, formal or final.
Hidden states are especially important. A happy-path screenshot does not show a required-field error, alternate host display or post-submit result. Inventory from the source template plus real interaction. If the tool exports a localization catalog, compare it against the card schema to detect authored strings that were not exported.
5. Separate a visible title from an action’s identity
An action’s visible title tells the person what will happen. Its internal type, ID or data payload tells the application what to do. Those jobs must not be conflated. A card may display an action whose title is ‘Send request’ while the payload contains a stable command like submit_application. Translating the title is expected; changing the command to a target-language phrase may break the handler.
The reverse problem is equally serious. A translator may preserve every technical value but translate ‘Decline’ as ‘Confirm’, causing users to submit the wrong action. A stable payload cannot compensate for a misleading label. QA should compare the semantics of the title and the action, not only check that the JSON remains parseable.
Test at least one execution of each important action. Inspect the received event or downstream result through the application’s approved test tools. Did ‘Cancel’ avoid submitting fields as intended? Did ‘Approve’ trigger approval rather than rejection? Did a ‘Learn more’ link open the correct destination? A card is complete only when words and consequences agree.
6. Example: a simple decision card
Consider an illustrative card that asks an employee to accept or decline a meeting request. Its text reads ‘Can you attend the training at 3 pm?’ and the actions display ‘Accept’ and ‘Decline’. The application receives distinct internal values such as attend_yes and attend_no. Those values are examples of one application’s contract, not universal Adaptive Cards keywords.
A target translation should preserve the future attendance question, not replace it with ‘Did you attend the training?’ That seemingly small tense shift changes an intention question into a retrospective report. Likewise, ‘Maybe later’ is not a faithful substitute for ‘Decline’ if the workflow records a definite refusal. The data contract must match the user’s reasonable interpretation of the words.
A functional test should send both actions and inspect the resulting status. A language reviewer can then confirm whether someone would understand the target label as that status. Two approvals are needed in principle: the user-facing meaning and the technical event mapping.
7. Handle mixed static and dynamic content deliberately
Many cards combine fixed language with live values: ‘You are approving request {requestId} totaling {amount} for {department}’. The fixed words carry the approval meaning; the placeholders supply data. If a localization export captures only static literal nodes, mixed expressions may be missed. Microsoft’s Copilot Studio guidance distinguishes static card text from mixed content and documents a way to make the mixed string available through the localization workflow.
Do not build target sentences by concatenating small fragments such as ‘Approve’ + amount + ‘for’ + department and assuming every language can use the same order. Some languages need different noun forms, particles, word order or agreement. Translate the entire human sentence as a unit while preserving the permitted placeholder identifiers. The application can then render dynamic values in positions appropriate to the target grammar.
Test with more than one input. A short department name might fit, while a long one wraps. A zero amount, large amount or negative adjustment may change the sentence’s natural reading. The translation must be robust to the kind of data the system actually inserts.
8. Protect identifiers, expressions and payload objects
JSON keys such as type, id, body, actions and schema-defined property names are not ordinary prose. An input ID can be a contract with downstream code. An action’s data object may contain routing information that should remain stable across locales. Expressions embedded in templating layers have their own syntax and must not be casually rewritten by a translation editor.
Create a protected-field list based on the actual card schema and the application’s own conventions. Do not extrapolate that every JSON string is untranslatable. A title value on an action is normally human-facing, whereas a developer-defined requestType value may be a machine command. Some fields can contain both text and expressions, requiring a deliberate extraction strategy.
A practical round-trip test serializes the localized card, validates the schema and compares protected values against the source. It should report meaningful differences, not demand textual equality of the language fields. A reviewer needs to see that the message changed while the event contract did not.
9. Labels and placeholders do different work
An input label identifies what information is requested. Placeholder text inside an empty field may illustrate a format or provide a hint. A translation that retains only the placeholder can create accessibility and usability problems when the user enters a value and the hint disappears. The schema and host version determine available labelling features; verify the actual rendered behaviour.
For example, an input labelled ‘Parent’s mobile number’ may have placeholder ‘e.g. +65 9123 4567’. The target label must still name whose number is needed. The placeholder’s sample number is not necessarily a contact number; it is illustrative format guidance. Do not replace the label with ‘Phone’ if that could mean the student’s, parent’s or emergency contact’s phone.
Test with the field both empty and filled. If the user revisits the card after a validation error, can they still tell what the value means? Ask a screen-reader reviewer or use appropriate assistive testing to verify that the control has an intelligible accessible name. Visual beauty is not proof of accessible form semantics.
10. Validation errors are part of the translation
A required field may show an error only when someone submits a blank form. If this text remains English, a user of the localized card may know that something failed but not how to recover. Translate validation messages so they identify the actual field and the required correction. A generic ‘Invalid’ is often less useful than ‘Enter a contact number with the country code’ when that is genuinely what the validator demands.
The words cannot change the validation rule. If the field accepts only a particular format, say so accurately; do not promise acceptance of spaces, punctuation or national formats the backend rejects. If the rule is inappropriate for international users, raise a product defect. It is a developer and policy decision to broaden accepted input, not a translator’s permission to misdescribe the constraint.
Test a blank submission, an invalid value and a corrected value. Check that the target error appears on the correct field and that successful recovery works. This three-state test is often more useful than a dozen screenshots of the untouched initial card.
11. Treat dates and times as data plus language
A card can display a meeting time, booking deadline or expiration. Translating surrounding words does not automatically solve locale-specific formatting or time-zone interpretation. A string such as ‘Training begins on 11/12 at 03:00’ is ambiguous without date-order and timezone context. A translator should not guess which date was intended or silently convert the clock time from an assumed locale.
Where the host supports date and time formatting, use the documented functions or formatting layer appropriate to that host. Ensure the underlying timestamp remains correct. Where the application supplies preformatted text, confirm that the same time zone and calendar date are shown to the relevant user. A target sentence may need a different ordering, but the temporal event is still one event.
A test set should include dates near midnight, month/day values both below twelve and locale switches. For a school form, check the Singapore-local deadline explicitly if that is the intended rule. An attractive localized sentence with the wrong closing time is not a successful translation.
12. Distinguish display values from stored option values
Dropdowns and choice sets often have human-readable titles and machine-readable values. A visible option might say ‘Parent’, ‘Guardian’ or ‘Other’, while the submitted value is an internal code. The title should be translated; the code should remain consistent with the receiving system unless a separate authorized data migration is performed.
Suppose a school form has two choices: ‘Attending with an adult’ and ‘Student attending alone’. If the target language inadvertently makes both choices sound like adult attendance, the form becomes useless even though its option values remain stable. The backend records two different codes, but the user cannot make the intended distinction.
After translation, ask a language reviewer to describe what selection each option would represent. Then select each and inspect the resulting stored value. The first check tests human meaning; the second tests application meaning. Both are required because neither can infer the other reliably.
13. Avoid source-language fallback hidden in templates
A multilingual app may switch its surrounding chat messages to a target language while a card remains partially English. The cause may be a literal string in an unextracted JSON template, a missing resource key, a fallback to a source catalog or a dynamic string assembled outside the localization workflow. Do not assume the language setting failed globally just because one card element is English.
Trace that element back to its data source and determine whether it was eligible for extraction. In Copilot Studio, current guidance makes a specific distinction for mixed strings that combine variables and static text. In other implementations, the issue may be a developer-defined resource lookup that never receives the target locale. Fix the owning layer and add a regression case.
A useful QA report lists each target card’s percentage of localized visible strings and separately flags safety-critical or action-critical gaps. However, a coverage percentage is not a quality score. Ninety-nine translated labels do not make up for one untranslated ‘This action cannot be undone’ warning.
14. Render in the host, not only in a JSON validator
A valid Adaptive Card schema proves that a document follows certain structural rules; it does not establish how every host renders the card. Supported features, fonts, layouts, overflow behaviour and action handling can vary by host and client version. A card that looks excellent in a designer may need extra testing in Teams, Copilot Studio or another actual destination.
Test the target text at a normal width and a narrow screen. Long action titles may wrap, be truncated or force awkward layouts. Check that the most important button remains visible and distinguishable. Some target languages take more space than English; the solution may be flexible layout rather than deleting essential meaning from a warning or commitment.
Do not promise universal host compatibility from a single test. Record the host, client and version boundaries used. A ‘passed’ result means the tested configuration passed its defined cases. It is not a blanket statement about every application that can render Adaptive Cards.
15. Check accessibility labels, errors and action meanings
Accessible text can include labels, image alternatives, help content and action descriptions that are not prominent on screen. Translating only visible headlines leaves some users with incomplete language access. Microsoft’s localization guidance explicitly lists image alt text, error messages and placeholders among static text surfaced by its workflow, which underscores that card localization includes more than TextBlock body text.
A card with an approval icon should not rely on the icon alone to communicate ‘Approve expense’. Give the user a precise accessible label when the platform supports one. Check contrast and typography through rendering, but also listen to the order in which assistive technology announces the prompt, value and action. A string can be correctly translated and still appear in an illogical focus sequence.
Where an implementation limitation prevents a usable accessible result, record the limitation and assign an owner. Do not quietly abbreviate ‘Delete the record permanently’ to ‘Delete’ without checking whether the omitted consequence is communicated elsewhere.
16. Keep numbers and money understandable
Purchase, attendance and reporting cards often show numbers, percentages or monetary amounts. The target translation should preserve their mathematical meaning and associated labels. A user must be able to distinguish $500 approved budget from $500 remaining budget, or 12 attendees from 12 available places. If a sentence is restructured, confirm which value each placeholder refers to.
Do not conflate currency translation with currency conversion. A total denominated in Singapore dollars does not become a euro amount merely because the surrounding text is French. Conversion is a separate financial operation with rate, rounding and date requirements. The card should display the authorized amount in a clear locale format while retaining the correct currency identity.
Test at zero, one and multiple units when grammar depends on count. A reminder saying ‘You have {n} request pending’ may need number-sensitive forms in some target languages. If the application cannot support them, escalate rather than producing ungrammatical or misleading output that looks correct only for the test value one.
17. A worked approval-card example
Imagine a school purchasing system that shows ‘Request for classroom microscopes’, ‘Requested by: Science department’, ‘Total: SGD 1,250’ and buttons ‘Approve’ and ‘Return for clarification’. In the target language, the translator must preserve a distinction between granting approval and asking for more information. ‘Return’ is not a shipping instruction here; it is a workflow state.
The backend uses stable action values approve and needs_info. The language reviewer translates the verbs for a manager who is responsible for financial authorization. The reviewer also checks that the currency is still SGD and the requested item has not become a different product category. A long translated title is allowed to wrap, but it must not push the consequence of approval entirely out of sight.
Functional QA submits both actions and inspects the resulting status. An incorrect mapping is a blocker even if all text is fluent. A bot reply after submission should also be localized; otherwise users can complete the card but receive a confusing source-language confirmation.
18. A worked parent-consent example
A tuition programme wants a card asking whether a parent consents to a student joining an optional revision session. The source asks: ‘May we include your child in the Saturday revision session?’ The choices are ‘Yes, include my child’ and ‘No, please do not include my child’. The target must retain that this is optional and future-oriented. A translation that says ‘Your child will attend Saturday’ turns a request into a declaration.
The form also asks for a preferred contact number. That field should not be relabelled ‘Emergency number’ unless the process genuinely uses it for emergencies. A blank field should trigger the correct target-language error; a decline should be processed as refusal, not as a technical failure.
The final confirmation needs careful wording. If the parent declined, a message saying ‘Registration completed successfully’ could imply inclusion. A better response reflects the actual selected outcome, using approved workflow text. Localization QA includes the closing state because it confirms what the user has done.
19. A worked IT support example
An IT support bot sends a card with ‘Choose the problem you are experiencing’ and options ‘Cannot sign in’, ‘Password reset’ and ‘Account locked’. A translator might collapse the first and third into similar phrases. In practice they can route to different teams or self-service steps. Preserve the distinction the system uses and describe each option in the target language so users understand their likely next action.
The values submitted might be codes such as sign_in_failure, reset_password and locked_account. These codes should stay stable unless the application has an authorized mapping layer. Test the target card by selecting each option and confirming the next screen. An accurate label leading to the wrong repair flow is still a failed interaction.
This case illustrates the importance of action consequence in localization. The reader’s job is not to admire a correct translation; it is to get help. A fast translator protects that journey through targeted test cases instead of translating an entire support system without knowing how its choices branch.
20. A worked appointment-change example
A clinic-adjacent administration workflow asks a user to choose ‘Keep appointment’, ‘Request another time’ or ‘Cancel appointment’. These actions may have very different consequences. The translated labels must not make ‘request another time’ sound like a confirmed rescheduling. If the system only initiates a request, the language should reflect uncertainty about the new slot.
The card might display a date and location supplied dynamically. Check that the target text does not move the date placeholder into a phrase that changes what it modifies. For example, ‘Your appointment on {date} at {clinic}’ should not make {clinic} sound like a staff member if it represents a location. Verify the formatting with a long location name and an actual time-zone test.
The result page should state the recorded outcome, not imply that a cancellation was accepted if the request is merely pending. A translator can identify this ambiguity but should have the process owner resolve it before release. Accurate status language protects users from missing appointments or assuming an administrative action is complete when it is not.
21. A worked bilingual quiz prompt
A learning app uses Adaptive Cards to ask a short Multiple Choice question: ‘Which action reduces the chance of electrical shock when replacing a bulb?’ The answer titles are translated, but each option also has a stable scoring code. A target version that removes the qualification ‘before replacing’ may change the temporal sequence and undermine the safety lesson.
The teacher records the intended principle: switch off and isolate power before handling the fitting, under the relevant equipment instructions. The target options must represent the same alternatives, including the distractors. The QA reviewer selects each option and verifies the recorded code, then checks the displayed feedback. The software engineer confirms that scoring is based on stable codes rather than translated labels.
The card is not an entire classroom assessment platform, but the lesson transfers: any interaction that records a learner answer has to separate visible wording from scoring identity. A language-only test is insufficient when a changed title can alter or obscure what the learner is selecting.
22. Review host-specific language and right-to-left layout
Arabic and Hebrew introduce additional layout and bidirectional text questions when combined with Latin IDs, URLs or prices. The correct target text may render poorly if the host applies an unsuitable direction or if punctuation appears visually detached from the correct field. Avoid inserting invisible controls everywhere without understanding how the host supports directional text.
Test real mixed content: an Arabic request, an English product code, a date and a link. Verify what users see, what they copy and what the screen reader announces. If the code becomes hard to copy, address the rendering layer and mark any intentional directional isolates carefully. A change that fixes one screenshot but breaks another locale is not robust.
The same principle applies to long words and scripts that use different line-breaking conventions. Review labels at large font settings and on narrow devices. A design that assumes every target button fits on one English-sized line needs layout repair, not pressure on translators to remove essential words.
23. Build a compact test matrix around decisions
Make one row per meaningful user journey. For an approval card, rows may include view without interaction, approve, decline, missing required field, invalid field, corrected field, source-language fallback and keyboard-only navigation. Columns can record displayed target text, intended action, actual payload, downstream status and accessibility outcome.
Choose representative data values for dynamic strings, such as a long person name, a high monetary amount, an empty optional note and a date near midnight. The matrix should be small enough to run repeatedly but broad enough to catch the real ways the card can fail. If a branch is technically possible but never exercised, it remains an untested risk.
When a defect appears, record its owning layer. CARD-07 / target error / incorrect contact-number instruction / wording should go to language review. CARD-07 / submit / value missing from payload / application handler should go to engineering. This classification makes re-testing faster and avoids vague messages such as ‘the translation doesn’t work’.
24. Avoid overselling automation
Resource export, machine translation and automated validation can make the work faster. They cannot determine every human commitment implied by a label. A tool may preserve the word ‘approve’ while missing that the source refers to approval of a proposal, not approval of an already spent expense. A schema validator may confirm the Action.Submit object while the application sends a data value that means the opposite action.
Use automation for exact comparisons, resource coverage, JSON parsing and repeatable submissions where test infrastructure permits. Use human reviewers for consent, obligation, safety, misleading option titles, cultural register and the meaning of results. Keep both layers visible in the release record so a team knows whether an item was actually evaluated or merely passed an automated syntax check.
Measure speed as completed, trustworthy interactions divided by total effort, including rework. A one-click machine translation that triggers days of support tickets is slower than a planned thirty-minute functional review.
25. Release checklist for a multilingual card
Confirm source template, schema version, host, locale and language ownership. Inspect every visible and conditional string. Verify that field labels and errors communicate the correct requirement. Check dynamic placeholder contracts, numbers, dates, links and currencies. Compare protected keys, IDs and event payloads. Render in the target host, including narrow-screen and assistive-use views. Submit each important action and inspect the response.
Then verify the status message or next step that appears after submission. A card localized in isolation can still be inconsistent with its surrounding bot topic. Record exceptions and approve only the intended scope. Preserve existing live templates and workflows until the application owner authorizes a controlled deployment.
If the project uses Copilot Studio’s localization export, follow Microsoft’s current instructions and validate mixed dynamic strings rather than assuming every visible expression is included automatically. If it uses another host, verify that host’s supported workflow rather than borrowing names or features that may not exist there.
26. Teach the method with a small diagnostic exercise
Create a disposable card with one headline, two choice values, a required text field and two actions. Ask students or trainees to mark each value as reader-facing language, machine identity or mixed content. Then show a target-language version with three planted faults: translated id, swapped action titles and a forgotten validation error. Have trainees explain the consequence of each fault from the perspective of the user and the backend.
The exercise reveals an important difference between surface correctness and operational correctness. A trainee may recognize that an action is wrong only after seeing a submitted status. Another may notice that the label no longer tells the user what to enter. Encourage them to identify which test would have caught each defect earliest.
Repeat with a card containing a variable amount and a date. The goal is not mastery of every JSON schema detail. It is a transferable habit: trace the wording through to the result, and protect the identifiers that allow the system to interpret the result.
27. Frequently asked questions
Does Copilot Studio automatically translate all Adaptive Card text?
It supports an export workflow for static card text, according to current Microsoft documentation. Mixed static-and-dynamic expressions need deliberate handling. Confirm the supported procedure in your environment and check the actual exported catalog.
May I translate input IDs and JSON property names?
Generally not as a linguistic operation. They are schema or application identifiers and may be required by handlers. Translate display values identified by the application contract, not technical keys on sight.
What is the difference between a button title and submitted value?
The title is a message to the person. The submitted value is data for the application. They must mean compatible things, but they are not necessarily the same text.
Why does a card remain in English after a language switch?
Possible causes include hard-coded text, missing resource entries, unsupported extraction of mixed content, a source fallback or an incorrect locale passed by the host. Trace the displayed string to its owner before editing.
Can I shorten a safety or consent button to fit?
Only if the shorter wording still communicates the actual action and its consequence. Prefer checking layout and host constraints before deleting decision-relevant meaning.
Does valid JSON mean the target card is correct?
No. It does not prove correct prompt meaning, accessible labels, data mapping, rendering, business rules or downstream workflow behaviour.
28. Transfer to other structured conversations
The same problem appears in multilingual web forms, school portals, kiosk screens, customer-service flows and interactive assessments. A reader sees a sentence and chooses an action, while the system needs a stable identifier to process that choice. Localization succeeds when the visible language and executable consequence remain aligned. Teams can then reuse the same method across products without treating every new platform as an entirely new kind of problem.
A good structure has separate owners for content, identity and behaviour. The translator can improve a phrase without changing a code. The developer can preserve a payload without dictating unnatural grammar. The content owner can revise a confusing business rule without hiding the change inside localization. Clarity at these boundaries makes the combined workflow faster and safer.
Summary
Microsoft Adaptive Cards should be localized as interactive decisions rather than static pieces of text. Extract all reader-facing language, keep the machine contract stable, give dynamic messages enough grammatical freedom, and test the entire path from prompt to submitted status. When the action a user understands is the action the application performs, multilingual card translation has done its job.
Related eduKateSG reading
- How People Translate Quickly | Series Index — the parent workflow hub.
- How People Translate Quickly | UI String Context — the separate problem of specifying string context.
- How People Translate Quickly | Inline Tags — protected formatting markers, distinct from card-level actions.
- How People Translate Quickly | Style Cards — consistent voice and register across repeated messages.
Sources and further reading
- Microsoft Learn, Localize Adaptive Card content, 2026.
- Microsoft Learn, Use adaptive cards in agents, accessed October 2026.
- Microsoft, The One Card: Build Once, Speak All Languages, updated August 2026.
- Microsoft Learn, Action.Submit schema reference, accessed October 2026.