How do you build a multilingual Claris FileMaker app when different users need different layout labels, menus, instructions and date formats? This FileMaker localization guide explains Get(SystemLanguage), Get(ApplicationLanguage), translated layouts, language preferences, translation tables, calculations, scripts, FileMaker Pro, FileMaker Go and WebDirect testing. It focuses on designing a reliable custom app rather than promising a single switch that automatically translates all its contents.
Claris documents distinct functions for the current system language and the FileMaker application language. It also documents the Set Use System Formats script step, which controls whether FileMaker Pro and FileMaker Go use current system formats or the formats saved in a file; WebDirect has different compatibility. These functions help a developer inspect the environment, but they do not by themselves translate every layout object, business record or custom menu.
Consider a multilingual repair-management solution used by engineers in different countries. One technician may see Spanish instructions and another Japanese field labels, but both must update the same asset record and preserve serial numbers, inspection results and authorization rules. A good FileMaker translation strategy makes that possible, survives upgrades and lets reviewers verify what the software actually did.
Quick answer: multilingual Claris FileMaker apps
Identify your clients, keep custom app language preferences separate from system and FileMaker application language signals, and implement approved text through either language layouts or a translation-key table. Verify scripts, custom menus, dates, numbers, layout behavior and permissions in FileMaker Pro, Go and WebDirect independently. Keep authoritative record IDs and actions stable across every translated experience.
Before you begin
- Inventory FileMaker Pro, Go and WebDirect clients actually deployed.
- Choose source and target languages and an explicit preference policy.
- Define glossary terms for actions with consequences.
- Decide language-specific layouts versus dynamic translation keys.
- Use typed fields and stable IDs for authoritative data.
- Document format and script compatibility per client.
- Test accessibility, validation, role security and saved records.
The complete FileMaker localization guide
1. Start with the actual FileMaker deployment
FileMaker Pro, FileMaker Go and FileMaker WebDirect can present the same custom app through different clients. A script or display feature supported in one is not necessarily identical in another. Before designing translation, list the deployed product versions, hosting method, client types, supported operating systems, browsers and target languages.
A solution used only on desktop can make different layout decisions from one intended for technicians on mobile devices. Build and test against the real deployment rather than relying on a generic screenshot of an older FileMaker edition. Claris help includes compatibility details for individual script steps, which should be checked before using them as essential workflow components.
2. Separate FileMaker’s own interface language from solution text
A person’s FileMaker application may show its standard menus in Japanese while your custom solution still contains English layout captions and instructions. Get(ApplicationLanguage) reports the language of the client application; it does not certify that your custom layout and data have been translated. This distinction prevents a common assumption: detecting Japanese does not mean the developer has supplied Japanese business terminology.
Keep a separate language preference for the custom solution when needed. Verify the actual field labels, buttons, dialogs and records that the user sees, not simply the value returned by a language function.
3. Understand Get(SystemLanguage) precisely
Claris documents Get(SystemLanguage) as the system’s current language derived from the client’s regional-format configuration. Its returned language name is in English, even when the current environment is not English. For hosted files, the value comes from the client; FileMaker WebDirect uses browser language in this context.
That can help initialize an app language preference, but it should not be the only decision source. A French-speaking user on a shared English-configured workstation may explicitly prefer French. Test the function on each supported client and decide whether the user can override the detected environment in a controlled way.
4. Understand Get(ApplicationLanguage) separately
Get(ApplicationLanguage) reports the current FileMaker application’s interface language, not necessarily the language of the operating system or the user’s business-content preference. Claris documents its behavior for hosted databases and WebDirect, where browser language matters. A developer may inspect both values when diagnosing why a button label appears in an unexpected language.
Record them in a safe diagnostic screen only when appropriate, rather than exposing internal environment information unnecessarily. If the values differ, the app should use a documented preference policy. Do not quietly alternate between both values on different layouts, or users can see inconsistent language mid-task.
5. Choose a deliberate language precedence policy
A practical policy might check an explicit user choice first, then a stored profile preference, then an appropriate client-language signal, and finally an approved default language. The exact order is a design decision, not a rule imposed by every FileMaker app. Write it down before creating calculations and scripts.
Ask how language should behave on first login, after logout, when a user changes devices and when a shared kiosk is used. A session variable should not unintentionally leak a previous user’s preference. Test each branch of the policy, including unsupported system languages, incomplete translations and a missing user profile.
6. Build a small canonical glossary before layouts
In a repair solution, close, archive, approve, release and delete are distinct operations. Define them in the source language with a description of the actual record effect. Translators need more than a word list: give a sample screen, the relevant workflow and any irreversible consequence. Identify technical labels that should stay unchanged, such as model codes and serial numbers.
Keep approved translations and reviewers associated with source terms. When a business rule changes, review all related target phrases rather than mechanically reusing a familiar word. Terminology consistency is a practical safety feature in multilingual enterprise applications.
7. Compare separate layouts with dynamic labels
Two common design patterns are language-specific layouts and shared layouts that calculate visible captions from translation data. Separate layouts can make visual editing and target-language review straightforward, but changes to workflow structure may need replication. Shared layouts reduce structural duplication but require reliable lookup logic and careful performance testing.
Make a small proof of concept using one form, one portal and one confirmation dialogue before selecting a pattern. Check whether team members can maintain the solution. A clever dynamic label technique is not automatically better if ordinary editors cannot diagnose missing phrases or safely publish a revised translation.
8. Use layout copies only with a maintenance map
If you create English and Spanish versions of an inspection layout, write down which objects represent the same field and which scripts both use. Do not change the underlying table occurrence or relationship casually when copying. Give layouts consistent names and identify the source layout version they follow.
A newly required field or changed validation rule should trigger a review of every corresponding language layout. Test that both variants navigate to the same detail records, use the same authentication model and produce the same updated status. A translated layout that looks right but writes to a different field is a serious application defect.
9. Create a translation table with stable keys
For dynamic text, a straightforward schema can store a stable phrase key, language code, translation text, source revision, approval state and reviewer. The key describes the UI concept, such as action.submit.inspection, rather than storing the English wording as its identity. This makes a source copy edit less likely to break lookups.
A calculation or script retrieves the approved target text, falling back according to the app’s policy. Test missing keys and duplicate keys with synthetic data. The translation table should supply presentation text; business records and status codes must retain their own authoritative identities.
10. Decide how scripts access the selected language
FileMaker scripts can use variables and fields to track application state. Claris documents Set Variable, including local variables beginning with a single dollar sign and global variables using a double dollar sign. For a multilingual app, decide whether the session should hold the current language in a global variable, a global field, a user profile or a combination. Explain where it is initialized and refreshed.
Do not rely on a value left behind by another user on a shared device. Test opening a new window, changing accounts and re-entering a layout after a language switch. The result should be predictable for every client.
11. Do not make language selection a permissions system
A language variable must never decide who can see a confidential record or approve a repair. Those privileges belong to FileMaker’s security controls and the application’s role logic. Whether a person reads Spanish or Japanese, the same authenticated account should retain the same rights and the same server-side restrictions. Test unauthorized direct navigation to each language layout and attempts to trigger a script from a custom menu.
If the app has a public-facing view, ensure it cannot be used to bypass the role model. Translation changes presentation; authorization governs action. Keeping the distinction clear simplifies both auditing and maintenance.
12. Choose fallback behavior for incomplete translation tables
A new source button may not have an approved translation in every target language. The app needs a safe rule instead of displaying a blank action or a raw key such as action.commit. Decide whether to show the approved source-language phrase, a notice or a disabled feature while translation is reviewed.
For critical decisions, do not allow an ambiguous fallback that could mislead a user into an irreversible action. Record missing target values in a release report and test the rule on each client. A fallback is a temporary reading condition, not a substitute for translation work or user testing.
13. Translate layouts without translating record identifiers
A serial number, record UUID, part code or audit timestamp remains the same fact in all languages. The field label can change from ‘Asset ID’ to its Japanese equivalent, but the underlying identifier must not be altered. Keep database keys and related fields stable across layout variants.
Test searches and updates using distinctive identifiers containing leading zeros and letters. If a user copies an ID from an RTL interface or a mobile field, the exact sequence should survive. Localized presentation should never create a second business record simply because a translator chose a different word for the category.
14. Handle field captions and button tooltips consistently
A layout can contain visible text objects, button labels, tooltip descriptions, placeholder text and help instructions. Translating the big heading but forgetting the tooltip creates a mixed-language experience, particularly for new users. Inventory each user-facing object and connect it to the correct phrase key or language layout. A button labeled ‘Finish’ should agree with its tooltip and the confirmation that follows.
Test with the keyboard and screen reader where relevant. Accessible descriptions should communicate the same action as the visible text. Do not assume the FileMaker application’s own localization automatically covers your custom object wording.
15. Treat custom menus as another translation surface
Claris supports custom menus and menu sets in FileMaker Pro with advanced tools, including display titles that can be based on calculations. This offers a controlled route for custom labels, but it introduces maintenance and privilege considerations. A duplicated menu set can reference the same menus, so changes may affect more than one layout.
Record which menu is installed and where, and review its language with the matching layout. Ensure the menu action itself remains consistent with the label. Removing standard menu commands can also affect familiar shortcuts, so test keyboard behavior and access rights rather than simply translating the visible title.
16. Keep standard FileMaker commands in their supported context
A developer can customize some menu titles and commands, but not every built-in menu behaves like a free-form application label. Claris documents limitations on certain menus and how custom menu changes affect commands. Do not promise that a language setting in the custom solution will translate the whole FileMaker Pro program interface.
Instead, concentrate on the custom workflow and the menu items the solution actually owns. Test each client, because custom menus and WebDirect navigation may present differently. If a critical action exists through both a button and a menu, use one approved term and verify that both invoke the intended operation.
17. Understand system formats stored with the file
Claris explains that a FileMaker database file stores the date, time and number formatting of the computer on which it was created. Another user’s current system settings may differ. That can create warnings or unexpected display conventions when an international team opens a shared file.
Treat numeric and date presentation as an explicit design choice. Keep an authoritative calendar date or numeric value in the correct data type, then decide how the client should show it. Do not embed a country-specific formatted number in a text field and later assume it can be sorted or calculated safely as a number.
18. Use Set Use System Formats with compatibility in mind
The Set Use System Formats script step can make FileMaker Pro and FileMaker Go use current system formats instead of formats stored with the file, without changing the stored file formats themselves. Claris marks this step as unsupported for FileMaker WebDirect, Server and some other execution environments. Do not put it into a workflow and assume it works identically for all clients.
Decide where and when to invoke it, and test the date, time and numeric output. A startup script can help desktop and mobile users, but it must not be portrayed as a universal multilingual translation switch.
19. Make date entry unambiguous
If one technician expects day-month-year and another month-day-year, 04/05 can be misinterpreted. A layout translation may clarify the expected date format, while system-format settings can influence entry and display. Use a date field with an appropriate picker or unambiguous help text. Test a date where day and month are both valid, and another date where the distinction is obvious.
Compare the stored calendar date after save and reopen on another client. The same appointment must remain the same appointment regardless of which language the user selected. Do not infer time zone from language alone.
20. Treat time zones as a separate user need
System language, regional format and time zone are not the same dimension. A Japanese-speaking engineer may be working in Australia; an English-speaking manager may be reviewing records from Singapore. For event timestamps, decide which moment is stored and how different users should view it. Include an explicit zone when a deadline or scheduled service could otherwise be misunderstood.
Test near-midnight events and any relevant daylight-saving boundary. A translation changes the words around the time, but it should not silently change the scheduled instant. Ensure confirmation messages use the same authoritative event and clearly state the time convention.
21. Keep number formatting separate from mathematical values
A distance, pressure measurement or financial amount may be displayed with different decimal marks or grouping conventions. Store numerical values in typed fields and confirm calculations remain stable. A translated form must not cause 1,500.25 to become 1.50025 through a parsing assumption.
Test negative values, zero, large numbers, currencies and any rounded report summaries. If the business uses alternative physical units, implement a real conversion with labeled units and verified formulas. Simply translating ‘miles’ to ‘kilometres’ or changing a currency symbol is not a conversion and can materially mislead the user.
22. Handle currencies with codes, not only symbols
The dollar sign can represent different national currencies. If an international repair solution quotes charges in USD, SGD or another denomination, include an explicit code or clearly documented context where necessary. Keep the stored currency and exchange-rate logic separate from text translation. A language selector should not silently relabel an unchanged numeric amount as local money.
In a reporting layout, compare totals and individual line items in each language view. If conversions are offered, record the rate, effective date, rounding policy and approval. Review the result with finance owners, not only a language reviewer.
23. Translate validation messages without weakening rules
A FileMaker field validation can reject missing, out-of-range or invalid values. A custom translated message must describe the same rule that the actual field or script enforces. If the message says at least eight characters but the application accepts six, the translation is misleading regardless of its grammar.
Build test cases for blank values, long text, wrong type and out-of-range numbers. Validate each language route against the same underlying field and server result. Avoid using translated field captions as keys in business logic; source display text may change while the rule should remain stable.
24. Translate script dialogs with their actual consequences
A custom dialog may warn before replacing an inspection result or closing a case. Translate its title, body and button captions as one decision unit. A reader should understand whether the action saves, cancels, archives or permanently removes information. Test each button path with a reversible synthetic record and compare the stored state.
A dialogue can be perfectly translated yet still be confusing if the buttons are positioned or named inconsistently with the workflow. Capture the exact words and the result of each action. The goal is accurate consent to the operation, not merely a smooth-looking interface.
25. Localize found-set and navigation concepts carefully
Users of FileMaker solutions may work with found sets, lists, detail layouts and portal rows. A translation of ‘Find’ must distinguish searching for records from creating a new record. If the app uses a custom search screen, explain what fields are searched and whether partial matches are supported.
Test empty results, multiple records, sorted lists and a search involving non-Latin names. A user’s language preference should not change which records are permissible or which keys are used for relationships. When labels grow longer, ensure that controls still communicate the right destination and that row selection opens the intended record.
26. Keep user-entered notes in their source form
A technician’s note is authored evidence. A translated UI does not justify rewriting that note automatically, especially if it records an observed fault or safety incident. If translated versions are useful, store them as linked derivatives with the original language, source record ID, translation status and reviewer.
Display provenance so a colleague can inspect the source where there is ambiguity. A machine-generated translation should not be treated as a verified technical finding without review. This is particularly important for warranty disputes, compliance records and instructions that could affect the safe operation of equipment.
27. Design accessible text and controls
A multilingual FileMaker layout may use fonts and alignment optimized for English that do not display another script well. Test accented Latin words, Japanese characters and RTL content in the actual client. Ensure buttons remain large enough, text does not clip and keyboard navigation still reaches the correct control.
Check whether translated tooltips and accessibility descriptions are exposed appropriately for the deployed platform. Do not rely on color alone to communicate a validation failure. Readers should be able to associate a message with the correct field even when a target language expands into two or three lines.
28. Respect right-to-left and mixed-direction content
Arabic and Hebrew interfaces can require a different reading direction, while asset codes, serial numbers, dates and URLs should remain recognizable. FileMaker custom layouts may need deliberate object placement and alignment rather than an assumption of automatic mirroring. Build a sample containing an RTL sentence, a Latin part number, a negative quantity and a telephone number.
Test how the client displays and copies those strings. Native-language reviewers should confirm the result, especially if navigation arrows or progress directions are used. The safest pattern is not to reverse everything: it is to preserve each item’s correct reading and data sequence.
29. Consider FileMaker WebDirect as its own test environment
Claris documentation notes that language detection functions have browser-language behavior in WebDirect, while Set Use System Formats is not supported there. That means a desktop test cannot certify the web experience. Open the hosted solution in supported browsers with different language preferences and inspect layout labels, scripts, record views and form submissions.
Test both a freshly opened session and an authenticated returning user. Watch for differences in custom menu availability, responsive sizing and language preference persistence. Record confirmed behavior for the actual supported WebDirect version and avoid making unsupported platform-wide claims.
30. Test FileMaker Go with real device conditions
Mobile readers may use different system languages, keyboards, regional formats and screen sizes than desktop developers. Because Set Use System Formats is supported in FileMaker Go, test its intended configuration without assuming every other desktop behavior is identical. Enter a date, numeric measurement and non-Latin text on a physical device or equivalent supported test environment.
Change the user’s explicit app language and revisit the same record. The saved values and relationship keys should remain unchanged. Inspect long buttons, popovers and virtual-keyboard behavior so a translated interface remains usable when space is limited.
31. Use a versioned translation review process
Source-language changes may appear in scripts, layouts, menus and message tables. Track the changed string, workflow, approved target language, review date and responsible person. A field renamed in English may need new Japanese and Spanish wording even when its technical identity does not change.
Do not rewrite all translations after every small change; maintain stable keys and targeted reviews, while reopening any concept whose operational meaning has changed. Include screenshots for ambiguous short strings such as ‘Close’ or ‘Charge’. Language review belongs alongside application testing, not after the release has already reached users.
32. Build a complete bilingual test case
Use a synthetic inspection with a unique asset ID, a due date, a numeric value, a free-form note and an approval status. Complete it in English, then repeat the equivalent journey in a target language with another test record. Check navigation, search, validation, confirm and report views.
Compare the persisted field values and security outcomes; only display labels and appropriate formatting should vary. Ask a native-language reader to complete the target journey without coaching, and note any wrong assumptions or hesitation. A full test reveals issues that a translation-table audit or layout screenshot cannot catch.
33. Test failure, cancellation and recovery paths
Most demonstrations show only a successful submission. Real users experience wrong passwords, missing fields, failed saves, network interruptions and accidental navigation. Translate the messages for these cases and make the recovery route understandable. Ensure a failed operation does not produce a success confirmation in another language.
Test cancellation of edits, closing a dialog and returning to a list without changing the record. For remote clients, check behavior after an interrupted connection using safe sample data. A localized app is dependable when users can tell what happened during failure as well as success.
34. Keep search and reporting stable across languages
A translated report header does not automatically translate every search index or customer-authored phrase. Decide whether the solution searches canonical values, language-specific labels, original notes or approved translation derivatives. Stable status codes should remain usable even if their display terms change. Test leading-zero IDs, non-Latin names, sorting and a date filter on each client.
Record any intentionally different search behavior. If the application uses a translated picklist, verify that selecting a target-language label applies the same underlying status or category predicate as selecting the source-language label. A readable report must also be a truthful report.
35. Plan release and rollback around real dependencies
Before publishing a revised FileMaker solution, identify every affected layout, script, translation record, custom menu and client type. Keep the approved previous version and the tested route to restore it if a critical label is wrong. A rollback should preserve newly created business data and not silently revert transactions. Assign owners for the source process and each target language.
Document known limitations and a support contact. If a translation affects an irreversible action, require an explicit outcome test before release. The audit trail should explain what changed, who approved it and what evidence confirmed the same result across languages.
36. Do not promise multilingual SEO from a FileMaker layout
A custom business app is not automatically a set of public search-indexed pages. Translating layouts inside FileMaker Pro or WebDirect does not by itself create public localized articles, distinct search engine URLs or hreflang metadata. If an organization also needs public help content, publish and review it through an appropriate website system, maintaining access separation from private operational records.
Support pages can explain the available app languages and common tasks without exposing confidential data. Keep multilingual public discovery and authenticated application localization as related but distinct workstreams, each with its own quality checks.
37. Measure the user’s understanding, not just translation coverage
A language dictionary can contain all expected keys while a technician still misunderstands how to save an inspection. Ask target-language participants to perform realistic tasks independently, including one invalid input and one consequential action. Capture which word confused them, whether the information was visible at the right moment and whether the same authoritative result was saved.
Use that evidence to improve captions, layout and help instructions. A complete translation is not simply a file with no missing rows. It is an application in which people who read different languages can make the same informed choices and reach equivalent results.
Twelve acceptance tests for FileMaker translation
Use synthetic records and approved staging files. Record the client version, language signals, selected application language, expected action and resulting database state. Test each supported client rather than assuming desktop behavior applies to the browser or mobile app.
Test 1: Two language functions, one user
Record the values of Get(SystemLanguage) and Get(ApplicationLanguage) on a controlled test device. Compare with the custom solution’s preferred language. Confirm that the app chooses the documented preference rather than assuming both functions always agree.
Test 2: WebDirect browser preference
Open the same hosted solution from a browser whose language differs from the desktop user’s setting. Check both language functions, the selected custom layout and all visible captions. Do not rely on a desktop script step that is unavailable in WebDirect.
Test 3: Separate layouts, same record
Open one synthetic inspection through English and Japanese layouts and change a field in each. Confirm the same record ID and field mapping are used and that the two routes enforce identical validation and permissions.
Test 4: Missing translation-table key
Temporarily omit one low-risk target phrase in staging. Verify the documented fallback, the visible label and the missing-key report. Critical controls must not display an unexplained raw key or an unsafe guessed translation.
Test 5: Session language after logout
Choose Spanish, log out, sign in as a different user and confirm the new account’s preference takes effect. Shared devices must not carry an earlier user’s language or access to their data.
Test 6: Date format compatibility
Compare a stored date in FileMaker Pro, FileMaker Go and WebDirect under the intended regional settings. Where supported, exercise Set Use System Formats. The calendar date must remain correct even when presentation differs.
Test 7: Mixed numeric formats
Enter a negative amount, a large value and a decimal measurement in each client. Confirm correct numeric storage, calculations and reported values rather than judging only what is printed in a formatted text object.
Test 8: Menu action equivalence
Activate the same custom menu command in two supported languages. Check its target script, role restrictions and record outcome. A translated title must not conceal a different or unavailable command.
Test 9: RTL technical identifier
Display an Arabic instruction next to a Latin asset code and a contact number. Copy the code, reopen the record and compare it byte for byte. Visual direction must not corrupt operational identifiers.
Test 10: Invalid submission
Trigger a required-field error, an invalid number and a cancelled save in the target language. Confirm the messages explain the actual rule and that no misleading success state is shown.
Test 11: Translated free-form note
Create a synthetic maintenance note in one language and a separately approved derivative in another. Confirm provenance, reviewer status and unchanged original text in the linked record.
Test 12: Rollback rehearsal
Change one staged high-visibility caption to an obviously incorrect test phrase, restore the previous approved translation state and retest the same workflow. The restored version must not alter business data or user privileges.
Frequently asked questions
Does Get(SystemLanguage) translate a FileMaker layout?
No. It reports a client language signal. Your custom layouts, labels, messages and data need their own language design and review.
What does Get(ApplicationLanguage) mean?
It reports the FileMaker client’s application interface language, which may differ from the system setting and the user’s preferred custom-app language.
Should I make one layout per language?
That can be practical for limited languages, but dynamic caption lookup may reduce duplicated structure. Choose based on maintainability, performance and testing.
Can I use global variables for the selected language?
Yes, scripts can manage session state. Initialize it predictably, document persistence, and avoid letting a prior user’s preference or access state leak into another session.
Does Set Use System Formats work everywhere?
No. Claris marks it supported in FileMaker Pro and Go, but not in WebDirect or several server-side environments.
Should record keys be translated?
No. Keep identifiers, status codes and relationships stable while displaying localized labels appropriate to the user’s task.
Do FileMaker menus translate automatically when I change a custom variable?
Not universally. The application interface and custom menu configuration have separate controls and limitations. Test the particular client.
How should user-authored notes be handled?
Keep the original note as authoritative evidence and store any approved translated versions as linked derivatives with provenance.
What about right-to-left languages?
Review layout placement, reading direction and mixed-script values explicitly. Never assume that reversing all visual elements preserves identifiers and meaning.
When is the release complete?
When target-language readers can complete the same authorized workflow and the persisted data, calculations, confirmations and errors remain equivalent across clients.
The reliable release standard
Claris FileMaker provides client language signals, scripting, layouts and formatting tools that can support a thoughtful multilingual solution. The developer still has to author and maintain the translated experience. A trustworthy release preserves the same authenticated permissions, source facts and business outcomes while making each supported workflow understandable to its intended readers. Review full tasks and recovery paths, not only visible captions, and keep the original record available when translated information is uncertain.