Developing a multilingual FileMaker custom app

One of the most common design concepts for custom app accessibility is the ability to support multiple languages. Globalization, the practice of making something work in multiple locales, is an important business consideration for software developers. So, learning techniques to achieve localization of your FileMaker custom app will allow you to offer globalized apps and services.

Native FileMaker language support functions

FileMaker supports 11 languages out of the box. These features are seen in several base functions of the FileMaker app itself, such as:

• Installers and configuration wizards for FileMaker software
• Dictionaries used for spell checking. This is also passed on to various dictionary/spelling script steps that can be used to build localized interfaces.
• Vertical writing. FileMaker is a popular app because it’s one of the only database formats that natively supports vertical orientation (top-to-bottom, right-to-left) text orientation, along with several functions to work with foreign languages.

Multilingual custom app concepts

Developing a multilingual custom app revolves around the following concepts:

1. User Detection: The process in which you will determine what language to load and present to the user.
2. Dynamic Objects: Pieces of your system that can change in a dynamic fashion, usually in FileMaker this is determined by if something can interact with the calculation engine or not.
3. Stacked Objects: In cases where you can’t create a dynamic object, the “stacking” method can be useful. In this technique, you stack all the objects for each language on top of each other, then hide the objects you don’t need.

At each step of the way in building your interface, it’s best to plan according to your app’s needs. For example, are you converting a mature app into a new multilingual interface? Or are you building this from the ground up? Are you planning to support two languages, or 10?

Three ways to deploy a multilingual custom app

The three major ways to deploy a multilingual custom app are:

1. Data Separation Model: Using a separate UI file for each language to support, a user will switch to the interface file appropriate to their language need. While this makes it easier to switch users and isolate language specific development, it makes support more difficult. For instance, if you want to deploy a change and you have five languages, you will need to deploy the changes five times. So, this method is more suited for mature apps where the interface and functionality is less likely to change.
2. Duplicate Layouts: Similar to the data separation model, you will use separate layouts for each language you support. While this can be advantageous for complex layouts, the downsides are also the same in multiplying the amount of work you have and the number of layouts you have. In this case, it’s almost always better to use the data separation model.
3. Dynamic Layouts: Requiring the least amount of UI layouts and objects to support, this technique allows your layouts to change dynamically based on your settings. This technique is also a bit more difficult to integrate, but the reward is a more dynamic approach that makes it as easy to support 10 languages as it does two.

Multilingual FileMaker app demo file

During my presentation at FM Conference Yokohama, I presented some of the techniques required in order to create a multilingual FileMaker custom app. Please see the attached demo file for inspiration. Look out for the following techniques you can use in your own development.

Using a popover object and a button bar (left), the file will “load” the languages into the interface. This is done through a script that sets global variables for the selected language, including loading values from a language table that are used for labels.

The “exploded” view for the stacked demo (below). This shows how you can use the hide object when calculation in FileMaker in order to hide the objects you do not want to see.

The LanguageTags layout (left). This is a table where you can hold values that will become global variables later through the dynamic loading script. You can create as many language tags as you need here without any further scripting. Each global variable will then be available as a merge variable to use on layouts.

The Contact Detail layout (below). Here you can see how merge variables are used to display dynamically loaded tags for the final result.

There’s more in the file so feel free to look around and borrow what you need to make your own multilingual custom app!