eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How People Translate Quickly | vCard 4.0: Translate Contact Names and Roles Without Mixing Up People

—

by

eduKate Asia

How People Translate Quickly | vCard 4.0: Translate Contact Names and Roles Without Mixing Up People

How do people translate vCard 4.0 contact information quickly without corrupting the contact itself? Preserve the person or organization’s identity and stable communication details, and use the format’s language and alternative-representation parameters only where appropriate. The LANGUAGE parameter can identify the language of a relevant value, while ALTID groups alternative forms of the same logical property. Translate descriptive roles or authorized names, not telephone numbers, email addresses or identifiers simply because they contain recognizable words.

This vCard 4.0 multilingual contact QA guide addresses schools, event organizers, museums, directories, translators and developers who exchange electronic business cards across languages. A .vcf file is structured data, not just a list of editable lines. A contact named ‘Harbour Science Museum Visitor Desk’ may have an English and Chinese display label but only one telephone line and one actual institutional identity. Poorly chosen translations can create duplicate contacts, misleading roles or addresses that no longer deliver mail.

The fast method is to inventory fields, establish the canonical identity, choose which values need true language alternatives, apply valid vCard serialization rules, import into representative contact apps, and compare the resulting records. We use a fictional museum visitor desk and a bilingual school-family liaison as examples. A successful translation lets a reader recognize and contact the same person or organization, not a similar-sounding but different entity.

Start with the human contact task

People often say ‘translate this contact’ without identifying what the recipient must do. A parent may need to recognize a teacher’s formal name, a visitor may need to find the museum’s ticket desk, and an event organizer may need to call the same mobile number from another country. Translation that only makes the card look attractive can fail these practical tasks. Start by asking which fields readers see, which contacts software merges, and what the recipient may be expected to dial or enter.

Define an acceptance scenario such as: ‘A Mandarin-speaking visitor imports a card, sees the authorized Chinese desk name, and calls the same international-format phone number shown to an English-speaking visitor.’ The scenario identifies the important invariants: organization, phone endpoint and role. It also prevents a misleading shortcut where a translator creates an independent second contact with a translated name even though the same desk should be represented once.

Understand what vCard 4.0 represents

RFC 6350 defines vCard 4.0, a text-based interchange format for contacts. Records contain properties such as FN, N, ORG, TITLE, TEL, EMAIL, ADR, URL and UID, with property-specific cardinality, value types and optional parameters. A line of text has syntax and meaning beyond what a typical address book displays. The bytes you export may contain escaped characters, line folding and language metadata that disappear in a simplified user interface.

This matters because contacts applications are not necessarily full-conformance reference tools. One importer may preserve two alternative organization names; another may keep the first and discard the second. A vCard can be syntactically correct and still need a delivery fallback for a particular phone platform. Before promising interoperability, identify the actual exporters, importers and synchronization services used by the people receiving the file.

Keep identity separate from presentation

A person’s identity is not interchangeable with the spelling shown in a particular language. Official transliteration, an original-script name and a preferred display name may be related forms of the same identity. A role title, by contrast, describes work rather than who the person is. Do not translate a personal surname by dictionary meaning or assume that a Chinese name can be invented from an English name. Ask the holder for the correct script or use a clearly labelled transliteration policy.

For an institution, a second-language organization name should be the organization’s published translation when available. A local nickname may help visitors, but it is not automatically the registered name. Keep an authority record with source name, registered entity, official translations, abbreviation and role. When a translated card is used for a formal school contact, inaccurate institutional identity can lead to confidential messages being sent to the wrong office.

Use FN and N for their respective purposes

FN is the formatted name meant for display; N holds structured name components where supplied. They are not identical fields. A contact application may use the structured components for sorting, while the formatted form is what a reader recognizes. Do not copy a whole Chinese display name into an English given-name field just to force it to appear in the desired order. Respect each field’s semantics and the person’s preferred naming convention.

If a school staff member uses a two-part legal name and an English working name, decide whether these are alternate representations, a nickname or a separate display preference. Each case has different implications. A glossary cannot resolve personal identity on its own. Check the contact owner’s authorized preferences, test sorting in the recipient’s address book, and ensure a localized display does not erase initials or family-name distinctions needed for recognition.

Understand LANGUAGE and ALTID together

RFC 6350 describes ALTID as an opaque value used to group instances of the same property that are alternative representations, including translations with different LANGUAGE parameters. Two instances are alternatives only when their property names and ALTID values match. The ALTID value is not a language code and is not a global identifier; its purpose is local equality grouping inside the card. Treating each localized line as a separate organization or person ignores this relationship.

For example, two ORG properties with the same ALTID and different language parameters can represent the same museum’s approved English and Chinese names. Two lines with different ALTID values represent distinct logical occurrences rather than two forms of one occurrence. Cardinality rules also interact with alternatives. Test the actual property definitions rather than assuming every property can repeat indefinitely, and do not invent a second TEL merely because a country uses different words for ‘telephone’.

Read a small illustrative vCard

This fictional record uses FN and ORG alternatives to label the same museum desk in two languages. The telephone URI and email address stay identical. It is a teaching example, not a promise that every contact app will preserve all alternatives. The museum name is fictional and should not be used to contact a real institution. When an actual company supplies official translated naming, prefer that evidence to a translator’s improvisation.

BEGIN:VCARD
VERSION:4.0
FN;ALTID=1;LANGUAGE=en:Harbour Science Museum Visitor Desk
FN;ALTID=1;LANGUAGE=zh-Hans:海港科学博物馆访客服务台
ORG;ALTID=1;LANGUAGE=en:Harbour Science Museum
ORG;ALTID=1;LANGUAGE=zh-Hans:海港科学博物馆
TEL;VALUE=uri:tel:+6560000000
EMAIL:visitors@example.org
END:VCARD

The example’s basic envelope is straightforward, but real-world work requires more than copying it. Validate parameter syntax, property value escaping, UTF-8 content and the relevant RFC rules with an independent library. Some importers may collapse alternate FN instances or change the preferred display choice. Compare imported entries with the source and decide whether to distribute one combined card or separate presentation variants for compatibility while retaining a stable contact identity.

Protect the communication endpoints

Telephone numbers, email addresses, URLs and machine identifiers are endpoints. A translator should not replace their value to make the card look local. Converting a Singapore international number into a guessed domestic format can make it unusable for an overseas visitor. Translating the word inside an email local part is especially hazardous because the resulting mailbox may not exist. Keep these values unchanged unless their owner provides an explicitly verified replacement.

A safe workflow tests each endpoint rather than trusting the displayed formatting. Confirm whether a telephone value is a tel: URI, whether an email address contains the correct domain, and whether a website link redirects as intended. Never call or email a real person merely as a speculative QA test without authorization. For classroom examples, use fictional addresses and reserved example domains. A contact card is personal operational data, not a harmless article snippet.

Translate job titles without upgrading authority

TITLE can describe a job function, and ROLE may describe organizational role, depending on the card’s data model and usage. Their words can be translated, but they must preserve the actual responsibility. A ‘visitor support assistant’ is not the ‘museum director’; a ‘school family liaison’ is not necessarily a licensed social worker; a ‘laboratory technician’ is not automatically the principal investigator. A prestigious title may sound more natural but can change whom recipients trust.

Ask the organization to approve the equivalent title. Where job structures differ between countries, an explanatory phrase may be better than using an apparently equivalent formal rank. Keep any organizational department or escalation contact consistent with the person actually responsible. The real test is whether the recipient asks the right person for the right kind of help. An inaccurate title can lead to missed deadlines or inappropriate disclosure.

Preserve formal addresses and delivery instructions

Postal addresses include structured components as well as street names, building numbers, postal codes and country information. A place name may have an established international-language form, but the address still needs to identify a deliverable destination. Do not translate a street or building name by its literal meaning unless that translated form is officially used for delivery. Preserve the postal code and any floor, unit or building identification.

If a card includes an address formatted for international mailing, test its practical readability with the local postal convention. Translation and reformatting are different actions. A target-language rendering may explain that ‘Blk’ is a Singapore block abbreviation, but it should not discard the official address line. When a contact’s public role differs from a confidential home address, follow privacy and directory-publication rules before reproducing any address at all.

Treat countries and locale preferences separately

The language a reader wants is not necessarily determined by the country associated with a contact. A Singapore organization may communicate in English and Chinese; a visitor from Europe may prefer Japanese; a staff member may use multiple scripts for a name. Use language tags for the language of each alternative value and a separate preference or policy to determine which to display. Guessing based on country codes can be both inaccurate and exclusionary.

A locale strategy should document fallback behavior. If there is no approved Malay organization name, the application can show the established English name with a clear label rather than silently machine-translating a legal entity name. For a display system, test how tags such as en, en-SG, zh-Hans and zh-Hant are matched. Do not label simplified characters as traditional characters because the app’s locale selector happens to be ‘Chinese’.

Do not confuse ALTID with contact deduplication

ALTID links alternatives for the same property within one vCard. It does not merge two unrelated vCard files, and it is not a replacement for UID where a stable record identifier is needed. If a directory exports an English card and a Chinese card separately, a phone may create duplicate contacts unless it recognizes a shared identity or the import workflow has controlled matching rules. Avoid assuming ALTID solves cross-file synchronization.

Test exports, imports and subsequent updates. A user’s edit to the preferred English name may overwrite the Chinese name in one app, while another preserves both. Document which information survives round-tripping. If the final audience uses an importer that drops alternatives, provide a deliberate fallback such as an approved bilingual formatted name or separate contact-file distribution with a documented deduplication policy, not a silent data-loss risk.

Understand property cardinality before repeating text

Some vCard properties can appear multiple times; others have limits, with ALTID alternatives accounted for according to the RFC. Adding duplicate lines for each language without regard to these rules can make a record invalid or semantically ambiguous. N and FN have particular expectations. A translation team should not treat every property as a free-form text field that can be duplicated with a locale suffix.

Start from a conforming source card and identify the allowed multiplicity for each translatable property. For an existing value, use the intended alternative-representation technique rather than stacking unrelated lines. Run a parser or validator configured for RFC 6350 and record warnings separately from importer quirks. A parser can check the structure, but a human identity reviewer must still decide whether two names really represent the same person or organization.

Preserve escaping, separators and line folding

vCard is a line-based format with meaningful separators, escaping conventions and folding rules. A comma or semicolon inside a name or address is not always ordinary punctuation; in some property values it separates components. A translator who pastes a localized organization name containing punctuation into an unescaped value may alter how a client parses it. Unicode characters also affect the number of bytes in a physical content line.

Test literal newlines, commas, backslashes and semicolons against the relevant property’s value grammar. RFC 6350 content-line folding is based on octets, not merely visual characters, so a long Chinese label can exceed a byte-oriented limit sooner than expected. Avoid cutting a UTF-8 multibyte sequence during serialization. Use a vCard-aware library to write files, and inspect the actual bytes in a fixture with accented and CJK characters.

Work with encoded contact values carefully

Not all values are plain text. TEL can use URI form, PHOTO may reference a media resource, and URL identifies a website. Replacing a path segment or URI because it contains an English word can break links. A data: URI or encoded image bytes are not material for linguistic translation. Look at the property type and allowed parameters before placing values into a translation queue.

A preprocessing step can classify candidate properties by semantics and block translation of technical values. For each allowed text property, retain the original value, any language parameter, ALTID membership and rendering context. If an importer or exporter changes the textual representation of a URI without changing its target, test that normalization explicitly. Do not let a translation memory treat a URL or a phone URI as an ordinary sentence.

Handle organization departments without inventing hierarchy

An organization name and its departments may be represented as structured parts. A school card could have an education office, admissions team and examination services unit. These units are related but not synonyms. Translating all three as ‘school office’ may remove information the recipient needs to decide whom to contact. Conversely, promoting a department name to the legal organization name can make the card appear to identify a different entity.

Create an organizational hierarchy chart or simple parent-child reference before translation. Obtain official target-language labels if available. For each field, ask whether it names the organization, an internal unit, a person’s job function or the location of a desk. Preserve those relationships even if the target language orders components differently. After import, verify that a visitor can still identify the intended unit without misunderstanding its authority.

Preserve pronunciation aids as aids

A school may add phonetic pronunciation or transliterated display forms to help parents address a staff member. A pronunciation aid is not automatically the person’s official name and should not overwrite original-script identity. Some contacts apps have dedicated phonetic fields outside core vCard 4.0, while others use vendor-specific extensions. These implementations require separate documentation; do not claim a universal standard property exists for every app’s pronunciation feature.

Keep an authorized display form and any separate pronunciation or transliteration in clearly described roles. A short note might explain how to pronounce a surname without rewriting its spelling. If the translation team cannot verify pronunciation with the person, label it as uncertain or omit it. For contact data, a courteous approximation is less important than preserving the owner’s preferred identity.

Review personal data minimization

A contact file may include mobile numbers, birthdays, home addresses, job details and photographs. Translating a business-card headline is not permission to redistribute private fields to external vendors or another jurisdiction. Determine which fields the recipient genuinely needs and which are necessary for the card’s purpose. A museum visitor desk likely needs a public phone and email but not a private employee address.

Use synthetic records for testing, restrict production files to authorized processors and delete unnecessary intermediate exports according to policy. Translation memory tools can retain sensitive values, so exclude endpoints and personal names from reusable public termbases. If a contact belongs to a minor or a school family, apply more careful access and consent controls. Integrity includes protecting people, not only producing technically valid .vcf files.

Diagnose a Chinese name mapped to the wrong staff member

A directory contains two staff members with similar Romanized names. A translator guesses Chinese characters from the spelling and assigns the wrong person’s original-script name to one contact. The email and telephone still point to the intended staff member, but a parent may recognize the Chinese name and send sensitive information under a false assumption. This defect cannot be detected by simple vCard syntax checks.

Repair it by confirming the original-script name with the actual person or a trusted institutional directory. Update the language alternative only after identity approval. Record which fields were wrong and whether the contact was already distributed. Test a recipient’s recognition rather than relying solely on spelling similarity. For future cards, prohibit unsupported reconstruction of names and require evidence for all alternative-script person names.

Diagnose a translated email address that bounces

A translator sees admissions@example.org and replaces ‘admissions’ with a target-language word. The card becomes visually consistent but references a mailbox that was never created. Some automatic translation systems will alter email text if it is not explicitly protected. The error may not appear until a student sends an important application inquiry and receives a delivery failure.

The repair is to restore the exact authorized mailbox, exclude technical endpoints from translation, and compare endpoints against a source checksum or field inventory. Where a bilingual helpdesk genuinely has distinct language-specific inboxes, the organization must provide and verify both addresses. They should be represented as real separate endpoints with purpose labels, not as imaginary translations of one address.

Diagnose ALTID values that group unrelated roles

A school uses TITLE;ALTID=1 for ‘Science Tutor’ and, in Chinese, a phrase meaning ‘Head of School’. Both lines share a grouping identifier, so the file appears to say they are alternate-language descriptions of one role. The syntactic grouping can be correct while the meaning is false. A contact app may choose either line based on language preference and present different authority to different families.

To repair, compare the job description and official role in both languages. Correct the localized title and keep the same ALTID only when the two values express the same logical property. If the individual genuinely holds two different roles, model them as distinct occurrences according to the relevant property rules, not as translations of one another. Test the imported card in both locales with a human reviewer.

Diagnose a contact that duplicates after import

A museum distributes one card with an English name and another with a Chinese name. Both share a telephone number, but the recipient’s phone imports them as two separate contacts. Later the museum changes its phone number and only one record updates. The recipient calls the obsolete number because it is attached to the apparently familiar Chinese name. This illustrates why separate-language export must include a synchronization and identity strategy.

Test the distribution format before public release. Prefer one conforming card with supported alternatives where possible, and verify whether the intended importer preserves them. When separate cards are unavoidable, document their relationship and update channel; use stable identifiers where supported. A printable bilingual contact page can sometimes be a safer fallback than relying on poorly supported import behavior. The correct choice depends on the recipient’s actual technology.

Diagnose an address that no longer reaches the building

An address contains a named road, unit number and six-digit postal code. A translator replaces the road name with its literal meaning and removes the unit number to shorten the display. The result is readable but may no longer match postal or navigation databases. The failure is especially costly when the recipient travels to a consultation or mails a physical form before a deadline.

Repair using the official postal address as the invariant. Put optional explanatory local-language notes outside the deliverable address field and test the formatted version in a credible local address service when permitted. Compare building identifier, unit, postcode and city information after every transformation. Translation should help navigation without substituting an address that has never existed.

Diagnose line folding that breaks Chinese text

A manual export script wraps vCard lines after seventy-five visible characters instead of respecting the octet-oriented folding rule. Because Chinese characters occupy multiple UTF-8 bytes, the file may contain an invalid split or exceed the expected physical line length. Some contact readers repair it; others drop the property. The problem may look like random missing text rather than a translation defect.

Use a standards-aware serializer and automated round-trip test containing Chinese characters, accented Latin letters, commas and long role descriptions. Validate that decoding returns exactly the intended Unicode sequence and that the contact app displays it correctly. Do not fix the problem by deleting essential role qualifiers to shorten the line. Formatting belongs to serialization; meaning belongs to translation.

Apply a changed-context transfer exercise

A school wants to distribute a bilingual contact card for its examinations liaison. The English record identifies ‘Senior Assessment Coordinator’, an official school telephone number and a general department email. A contractor proposes translating the title as ‘Examinations Director’, turning the email local part into Chinese, and exporting a second card without a shared identifier. What should be rejected, and what sequence would safely deliver a useful bilingual contact?

The correct answer is to preserve the real role, phone and email, verify the school’s authorized Chinese title and attach a language alternative to the appropriate text property. Keep ALTID membership consistent with logical equivalence, preserve any UID, validate the vCard syntax and test importer round-tripping in the actual target apps. If clients lose alternatives, choose a transparent documented fallback. The school should approve the content and confirm that no private contact details entered the public export.

Use a production review checklist

Verify the legal or preferred identity, original-script forms, organization name, department, job title, phone, email, URL and address against authoritative sources. Check which text properties were localized, whether language tags match the actual text, and whether matching ALTID groups truly represent the same logical value. Validate cardinality, punctuation escaping, UTF-8 serialization and line folding. Compare endpoints before and after using exact matches.

Then import the record into representative contact applications and inspect display name, sort order, role, organization hierarchy, communication endpoints and duplicate handling. Export it again and check whether approved alternative-language values survive. Record unsupported client behavior rather than claiming universal compatibility. A working contact is one the intended recipient can recognize, save, find and use successfully, not merely a .vcf file that looks correct in a text editor.

Respect the limits of cross-platform contact apps

RFC 6350 is a standard, but it does not guarantee that every operating system, address book, CRM and synchronized contacts service preserves all features equally. Some applications apply private extensions, flatten structured values or ignore ALTID. This guide cannot test an unnamed client on behalf of the recipient, nor can a bilingual file prove that the organization has approved its translated name. Interoperability is an empirical delivery question.

For high-stakes contacts, keep a verified plain-language web directory or controlled PDF reference in addition to contact exchange files when appropriate. A print-friendly version may be more reliable for school parents than asking them to install unsupported software. However, preserve a consistent identity and update channel across formats. A fallback that silently uses outdated numbers or role names is not genuinely safer.

Summary: one real contact, several readable forms

The safest vCard translation keeps the endpoint and identity constant while offering authorized language alternatives. Decide which property carries each piece of meaning, use RFC 6350 parameters correctly, and ensure that localized role labels do not upgrade or downgrade someone’s authority. Treat phone numbers, emails, official postal details and identifiers as data to verify, not phrases to embellish.

Speed follows from that separation. Translators can focus on names and descriptions with enough context, engineers can preserve syntax and round-trip behavior, and contact owners can approve identities and communication details. The best outcome is ordinary and practical: whichever language the reader sees, they reach the same correct person or desk for the same reason.

Decide whether multiple language entries need an explicit preference

A card may offer two correct labels while the recipient’s address book displays only one. The fact that two alternatives are equivalent does not mean they are equally preferred for every context. The contact owner may prefer an English form in professional correspondence and an original-script form for local visitors. Where the format supports preference semantics, apply them according to the relevant property and test interaction with ALTID rather than adding undocumented pseudo-parameters to satisfy a single app.

Build a display test using two recipients with distinct language settings and a third with an unsupported locale. Confirm that each sees a recognizable identity and that no title or affiliation is silently lost. Where the importer chooses one value unpredictably, decide on a transparent fallback for the intended distribution. Do not fix the problem by pasting all language forms into every field, because that may create unreadable names and break structured sorting. Preference is a display policy; the person’s identity remains the underlying reference.

Investigate stale contacts after a department reorganization

A school may merge two offices and retain one public phone line while changing department names. A translator working from an older card can reproduce a perfectly fluent but obsolete organizational label. If an admissions department has become a student services office, the source itself must be verified before localization. Old titles can misdirect families or imply that a particular employee still exercises responsibilities that have moved elsewhere.

Ask the institutional owner for a current approved directory entry and effective date. Compare organization, department, phone, email and public website together rather than treating each as independent. Update both language forms in a controlled export, and test whether synchronization replaces or duplicates the contact in common clients. Keep a correction notice or redirect from the old department page where appropriate, but do not modify existing public directories without authorization. Language accuracy depends on current organizational truth, not the age of a translation memory.

Translate notes without leaking confidential context

A NOTE property might contain directions for visitors, operating hours or internal context supplied by the card owner. It may also contain sensitive reminders, private descriptions or outdated information. A bulk translation service that exports all notes can expose private details unrelated to the recipient’s job. Before translating a note, decide whether it belongs in a public contact card at all. Classification and minimization precede word choice.

For a public museum desk, a permitted note might say that group visits require advance arrangements; the translator should preserve whether booking is required or merely recommended. Internal remarks such as an employee’s personal availability should not be included without permission. Check that the note survives escaping and line folding, and that screen readers present it in the correct language. A correct public contact card offers useful action information without exposing a staff member’s private records.

Distinguish display order from structured-name order

In some languages the family name is normally presented before the given name; in others the order differs, and personal preference may override common convention. An address-book system may sort by structured N components yet display FN as authored. A translator who rewrites the structured family and given components just to change the visible order can make alphabetic lookup wrong or place an honorific into the surname field.

Use the person’s confirmed name components and an authorized formatted display name. Test lookup by each script, including search by surname, and inspect what happens when the card is exported and reimported. Do not assume that a locale setting alone will correct wrongly entered name components. For a school staff directory, test whether two employees with similar names remain distinguishable after import. The practical objective is accurate recognition and retrieval, not compliance with a generalized cultural rule.

Control updates across bilingual directories and QR codes

Organizations increasingly distribute vCards through QR codes, email signatures, websites and printed materials. A translation project that updates only the website may leave old bilingual cards embedded in printed signs. The same contact may then have several stale versions with different titles or phone numbers. Treat distribution surfaces as part of the release inventory and distinguish static encoded QR payloads from QR codes that point to an updateable landing page.

Before printing, decode the generated QR code and verify that the vCard content matches the approved record. Test a phone import in each main locale and confirm whether later changes propagate. For static QR cards, plan replacement signage or an authoritative website reference when contact details change. Avoid embedding personal mobile numbers where a public departmental channel would be safer. A good localization strategy enables future correction rather than merely producing one attractive multilingual export.

Frequently asked questions

What does ALTID mean in vCard 4.0?

It groups alternative representations of the same logical property within the vCard. The value is opaque and compared for equality with other ALTID values for the same property.

Is ALTID a language code?

No. LANGUAGE identifies the language of suitable text. ALTID identifies which alternatives belong together.

Should translated organization names have different ALTIDs?

When they are alternatives of one logical organization-name value, the RFC’s ALTID grouping uses the same value. Distinct organizational occurrences should not be misrepresented as equivalent translations.

Can a translator translate the letters before an email’s at sign?

No. That is part of an email address and may change the mailbox. Use only verified addresses supplied by the organization.

Can a person’s Chinese characters be inferred from Romanization?

Not reliably. Confirm the person’s preferred or official original-script name through an authoritative source.

Does vCard 4.0 guarantee two names survive import into every phone?

No. Client support varies; round-trip tests with real intended apps are necessary.

Can a contact’s job title be freely adapted to local professional ranks?

No. It should express the actual role and authority. A local title that suggests a promotion or licence the person lacks is misleading.

Why does UTF-8 change line folding tests?

Some characters require multiple bytes. RFC 6350’s physical line-folding considerations are byte-oriented, so counting visible characters alone is insufficient.

Should postal addresses be translated?

Explanatory labels can be localized, but use the official deliverable address and do not invent translated street names or omit unit numbers.

How should a school test a bilingual contact export?

Validate syntax, compare protected endpoints, inspect both language displays, import and export through target apps, and confirm that the right family reaches the right office.

Authoritative sources