Fulcrum has enjoyed considerable growth in the past six months and we’re excited about that, considering that we are just getting started and many more innovative features are on the roadmap for 2013 and beyond. What we didn’t anticipate or predict a year ago was the growth of our international user base, especially on the Android OS. A large majority of our current user base resides outside of the United States and English is not their first or even second language, and in some cases, English is not spoken or understood at all. We recognized this at the outset when we started creating Fulcrum in the cloud for a global audience, we needed to enable any language on any device, based on user-driven requirements and we needed to make it simple, elegant and effective.
Fulcrum’s multi-lingual capabilities
We continue to work through many underlying engineering issues to improve the multi-lingual capabilities in Fulcrum, but the ability to design, deploy and use fulcrum apps in any language is a reality today. Here’s a short example of how to achieve this under the current architecture. As we improve these capabilities, we’ll update the FAQ and support documentation.
First, we’ll build the app in English as we would want it, including all conditional fields, choice lists, classification sets, visibility and requirement rules. This is a simple illustration showing two sections of a commercial building survey app we’ve built for commercial customers. I’ve shown choice fields with complex visibility rules in the following graphics to provide an example of the versatility of using different languages throughout the app design and implementation.
Once we have this built and tested on a mobile device (this is important to minimize rework before we build the second language sections of the app), we then recreate the sections exactly as they are in English, except this time we will edit aspects of the app to represent the language(s) we want to use in the field. We’re working on the ability to clone and copy an entire section, including all logic, field relationships and rules, but for the time being, this is how to get the job done.
When I do this, I typically open two browser tabs when logged in to the Fulcrum account so I can have a side by side view of the fields and choices I need to implement in the other languages, instead of toggling back and forth in the same view.
The process is fairly straightforward, and if the user is a native speaker, it will be a simple task to translate the English field labels and values to another language, in this case, Arabic. In building this app, I enlisted the help of some colleagues and friends who are native Arabic speakers. This is always preferred because of the contextual relevance of many geospatial terms differs if machine-translation is used such as Google Translate or Babelfish. These can provide a high percentage of correct, literal translations, but in our experience, the issue arises in not knowing which percentage is incorrect, or inaccurate in a geospatial setting, and so we would advise getting a first-hand, native speaker to provide any translations, and if the person is familiar with the geospatial industry, that’s of course, even better for the end results.
Once we’ve recreated the sections and subfields, conditional fields, visibility and requirement rules, we can then begin to edit for the secondary language(s), in this case, Arabic. I would also recommend pairing the bilingual sections in a sequential list vs. grouping the sections of one language together.
You will notice in the Data Name field in the Arabic language section, this still reads in English. It is important to leave this field in English, since this is the database name within the fulcrum architecture and at this writing, only supports English. There are a number of technical reasons why this cannot be changed to the secondary language, but suffice it to say, it’s necessary to leave it in English and as I’ve shown in the example, simply append the Data Name label with the name of the target language, in this case, it would be “street_names_arabic”. This is also helpful for any non-Arabic speaking people that may need to modify, manage or use the app or the resulting data from the field, in knowing what the field or choice list refers to in the original English section, in this case, “street_names”.
Once I’m done building the first section in Arabic, I move on to the next section and repeat the process until all sections, fields, choice lists, etc. in your app are duplicated and translated to the secondary language(s).
Then, to enable this properly on the mobile device, we need to provide the user with a choice of language on the handheld devices. Configuring it in this way, particularly when using the default options, will present the proper language version on the mobile device.
The next step in the process is the assign visibility rules to the individual language sections so that when a user chooses a language (default or not) on the mobile device, the selected language fields are presented to the user. Note; we do not advise presenting both (or all) languages to a user on the mobile device while in the field collecting data, as this is an inefficient use of time on location, particularly if the objective is to generate a bilingual database. This is better handled with post-field work by backend processing, translation, transliteration and faster processing speeds.
Here’s the interface for configuring the visibility rules for the Building Address section in English based on the choice of language above.
The same configuration is set up for the Building Address section in Arabic, based on the choice of language. Again, it is important to configure this for each section that you want to present to the user on the mobile device so that it shows up in the language they choose.
To demonstrate this on an iPad, the following graphic shows the user choosing English and all of the subsequent sections, fields, and choice values are presented in English. Including the street name fields on the mobile device. This is as the user would expect and need to conduct the field work.
However, if the user prefers or needs the form to be presented in Arabic, then a simple choice in the first field instantly modifies all sections, field names and choice values on the mobile device, enabling the user to complete the work assignments.
Have you taken advantage of the bilingual capabilities of Fulcrum? We would love to hear about it. If not, get started with Fulcrum for free to create your own custom bilingual apps.