The internationalization feature enables you to easily localize your forms for target audiences that vary in culture, region and language. supports all ISO 639-2 languages worldwide including RTL (right-to-left) languages. The list of available languages and locale codes can be configured in your instance of (On Premise only). Translations use UTF-8 encoding by default, but you may also upload ISO 8859-1 (Unicode) strings.
supports localization from the browser's locale setting. will recognize the browser locale and alter displays and input formats as well as language according to the user's setting. Setting this preference is browser-specific. Refer to the www.w3.org Internationalization website for information about language preferences and how to change those in a number of popular browsers. Here is an example using the Firefox browser:
To change your language preferences in the Firefox browser:
You can select a general language code or a language/country code. The image above shows the choices for Spanish, Spanish/Mexico, Spanish/Chile, and Spanish/Paraguay which appear as choices in the Firefox Language list. Notice the list of languages in the Firefox browser uses the ISO 639-1 two-character language codes and two-character country codes for most of the choices. This may not be the case for other browsers.
You can override the browser locale with the special locale URL parameter. This is often very useful for testing your language-specific localizations. The locale parameter is of the form ISO_639_2_CODE | ISO_639_1_CODE [ _ISO_3166_1_CODE ] - where:
There is a built-in locale method in that you can use in a Business Rule. This method returns the locale from the browser URL.
You can easily localize any form by clicking Upload Translation in the form's Action Menu on the Forms & Workflows Home Page. This opens the Multi Language Support home page for that form. The default locale is the original language you used in the form designer. Each new locale you create will appear on this page. In the example below this form was translated to Spanish.
The steps below describe the process of creating, testing, and using a Spanish locale translation for a form named Travel Request Form.
Here is an example locale properties translation file. This form contains several controls labeled in English. Also, you will always see the labels for the submit button and the save, load, and print icons. These can be localized too. In this example, only the field labels were translated.
# Default strings for formtype: Travel Request Form # Note that spaces in keys must be properly escaped with a '\' # Generated on: Wed Jul 15 21:49:45 EDT 2009 Buiness\ Purpose=Negocio Propósito Car\ class="Coche" Clase Departure\ Date=Salida Fecha Departure\ Time=Salida Tiempo EMail\ Address=Correo Electrónico Submit= load= print= save=
You will see a line for every control label in your form, message control text (if Save Value is checked), hint, help, etc. in the format:
Add translations for each text string to the right of the equal sign:
<Text String>=<Text String in Spanish>
First\ Name=Primero Nombre
You may find some strings in the default properties file that are not applicable to your form. Here are a few example strings that are only applicable if you're using the save/load feature or Electronic Signatures.
Save\ failed.\ Status= Save\ successful= Save\ this\ form= Saving= Section\ A= Sign\ this\ section= load= save=
Text strings inside of controls, such as the Add Files text in the Upload control are also translated using these files.
Some text editors cannot display all international characters in their default encoding setting. For example, if you add Arabic translations in a text file and try to save, you may see an error like "WARNING: Some characters cannot be converted to code page 1252 (ANSI - Latin I)". To resolve this, use the Save As function and change the encoding to UTF-8.
Some browsers have problems with apostrophe characters. To ensure that your translations are ok on all browsers you should use the HTML escape character in place of the apostrophe. Refer to this additional information describing HTML Reserved Characters.
# If this does not work in your browser: Initializing\ form=l'initialisation de la forme # Instead use the html apostrophe escape sequence like this Initializing\ form=l'initialisation de la forme
Use English alphabet characters only when naming controls. For example, controls named with ó as in Póliza may cause issues when the control is used in a business rule and with submission data.
Upload your translation file.
Choose the locale from the dropdown. In this example we choose Spanish.
On Premise customers - your system administrator can configure the list of available locales.
Cloud customers - contact Support to request additions to the locale list.
The important point to note is that the &locale=spa URL parameter is directing the server to translate your form into Spanish. The Test button and the Share button on the Locale Home Page add the locale URL parameter automatically. The Test & Share buttons on the Forms and Workflows Home Page do not set the locale URL parameter and thus revert to the browser's default locale.
When a form is used in production your end-users will most likely have their browser locale set to their language of choice and the form will automatically translate to their language. Otherwise, your website will have to append the locale URL parameter onto your form's URL. Appending the locale URL parameter is usually done only for testing your translations.
Translations use UTF-8 encoding by default but you may also upload ISO 8859-1 (Unicode) strings. If you are using Unicode, check the ISO checkbox above the upload button.
Error message strings that the designer adds to a form using the error message property are translated using these uploaded translation files. The translation of built-in error messages is done in the translation file located in the <frevvo-home>/tomcat/webapps/frevvo directory.
|You can only specify one translation per language. For example, if a browser locale is set to ger (German) or de-at (German/Austria), your form will be translated using the one german translation you uploaded.|
If you click the test button you'll see the URL with &locale=ger and you'll see your form translated to your german strings. And if you manually change the URL to &locale=de_at you will still see your german strings. frevvo falls back to the single german translation file.
To update an existing locale translation, edit the downloaded .properties file and re-upload it choosing the same locale name from the Choose Locale dropdown. This will replace the existing translation with the new translation.
will recognize the browser locale and alter displays and input formats as well as language according to the user's browser setting. Refer to browser Locale Handling for the details. You can override the browser's locale setting via the form's locale URL parameter which is typically only done for testing your translations. For example to render the form in Spanish rather than the default browser locale, add &locale=spa to the form Url. The Test button and the Share button on the Locale Home Page do that for you automatically. The Test & Share buttons on the Forms and Workflows Home Page do not set the locale parameter and thus use the browser's default locale setting.
On Premise supports the ability to customize runtime and design-time strings and add additional locales and RTL languages. Follow these steps to make any of these changes to your On Premise installation.
To add new locale codes to the Choose Locale dropdown and add/change which locales are right to left languages, update these two properties files located in the <frevvo-home>/tomcat/webapps/frevvo/Web-INF/data/users directory.
Refer to the steps above under Server Customization for the instructions to replace the /WEB-INF/data directory.
Runtime strings such as those found when a user logs in to access their task list, the login page, access denied messages, etc and Design-time strings such as those found in the palette controls, wizards, built-in error messages, etc. are localized in the default file in the WEB-INF/data/locale directory.
Follow these steps:
Copy the file "default" to a new file named using the ISO 639-2 three-character or the ISO 639-1 two-character language codes. For example, the German translation file can be called 'ger' or 'de', for English, you can use 'eng' or 'en'. The Portuguese translation file can be named 'por' or 'pt' and the Chinese translation file can be 'chi' or 'zh'.
Translation files can also be named to specify a country code. In this case, you must name the file using this format: <language code>_<country code>. For Example, let's say the Firefox browser is set for de-at (German/Austria). The translation file in the Web_INF/data/locales directory MUST be named de_AT. The de represents the german language, followed by the underscore followed by a capitol AT which is the country code for Austria. These file names are case-sensitive.
There are several files for specific areas of the application. The names of these files indicate the area for which the file contains externalized text strings:
frevvo-ui (currently covers the template install dialog)
Pre-pended the locale onto the file. For example for french, "form-designer-properties" becomes "fr-form-designer-properties". All 6 files are required for each locale in order for this to work properly. For example for french (fr), you must place the following files into WEB-INF/data/locales, even if not all of them are translated:
Here is a section of the chi (Chinese) translation file with translations for the palette controls in the designer. This file is included in the frevvo directory.
# Default strings in the frevvo UI # Form designer Text=ä»–é¥¿å°ä»– TextArea=ä»–é¥¿å°ä»–å•Šäººé¥¿å•Š Date=çš„å•Šä»–é¥¿ Time=ä»–æ²¡é¥¿ Date/Time=çš„å•Šä»–é¥¿ï¼ä»–æ²¡é¥¿ EMail=é¥¿æ²¡å•Šä¸€äº† Money=æ²¡å“¦å¹´é¥¿æœ‰ Phone=æ‰¹å’Œå“¦å¹´é¥¿ Quantity=åŽ»å“¦å“¦å¹´ä»–å“¦ä»–æœ‰ Number=å¹´å“¦æ²¡ä¸é¥¿äºº BooleanCheckbox=ä»–ï¼å‘ Image=å“¦æ²¡å•Šä¸ªé¥¿ Video=æˆ‘å“¦çš„é¥¿å“¦ Submit=æ˜¯å“¦ä¸æ²¡å“¦ä»– Cancel=æ‰å•Šå¹´æ‰é¥¿äº† Dropdown=çš„äººå“¦æ‰¹çš„å“¦æˆ‘å¹´ Radio=äººå•Šçš„å“¦æ‰¹ Checkbox=æ‰å’Œé¥¿æ‰å¯ä¸å“¦å° Section=æ˜¯é¥¿æ‰ä»–å“¦å“¦å¹´ Repeat=äººé¥¿æ‰¹é¥¿å•Šä»– Tabs=ä»–å•Šä¸æ˜¯ Tab=ä»–å•Šä¸ Panel=æ‰¹å•Šå¹´é¥¿äº† Table=ä»–å•Šä¸äº†é¥¿ Col=æ‰å“¦äº† Message=æ²¡é¥¿æ˜¯æ˜¯å•Šä¸ªé¥¿ Link=äº†å“¦å¹´å¯ Trigger=ä»–äººå“¦ä¸ªä¸ªé¥¿äºº Upload=å“¦æ‰¹äº†å“¦å•Šçš„
Setting the Firefox browser language to Chinese displays the designer palette controls as shown:
will detect the language setting of the browser and search for a corresponding ISO named translation file in the WEB-INF/data/locale directory. If a translation file exists, the designer and server-wide runtime strings display with the translations specified in this file. If the translation file does not exist, the designer and server-wide runtime strings display in English - the language of the default translation file. If a locale-specific file does not contain a particular property or string, then the English translation in the default file is used.
When you first examine the locale directory, you will notice a sample translation file named ger (German). Let's say you copy/modify the default translation file to make a second file for German named with the ISO 639-1 two-character code - de. Then you create/modify another German translation file and name it de_AT for German/Austria.
Select German/Austria (de-at) as the language in the Firefox browser and log in to as a designer user. The designer displays the translations from the de_AT file. If the de_AT translation file was not present in the WEB-INF/data/locale directory, the designer and server-wide runtime strings display the translations specified in the ger (German) file. If the ger file was not present in the locale directory, the translations in the default file (English) would be used.
To display the designer and server-wide runtime strings using the translations from the de (German) file, you would have to change the language in the browser to German (de).
There are two options for the runtime and design-time translation strings.
For example, let's say you are translating the designer to French (fr) and the French word for the Upload control is télécharger.
Here is what the Upload control looks like in the designer if the entry in the fre.unicode file for the French word for video contains the unicode equivalent for the é (\u00e9). The language of the browser is set to French.
|Unicode File with Unicode Equivalent||Upload Control in Palette|
The UTF-8 and unicode files for a language must reside in the <frevvo-home>/tomcat/webapps/locale directory. You can mix the two different file types with regards to different languages. For a particular language/locale, the system will try to load the UTF-8 version first.
To test that your Runtime string translations show up as expected, for example on your Task list, follow these steps.
If you append &locale=spa to the task list as a test as discussed above you will notice that ' surrounding page content is visible (as expected) and is not localized. This is correct and expected behavior. You are expected to embed the task list in your own localized website.
Test that your designer translations show up as expected by:
Date, Time, and Date/Time controls are locale-aware for both parsing and format. When the Automatic format is selected, both date and time entry and display formatting will be locale-specific. The designer has the option to set a particular date or time format independent of the locale by using the date format or time format property, but this is not recommended because it is not responsive to user locale.
Here is an image of Date/Time controls with the browser language set for German and the Date/Time controls set for Automatic. Notice the date format is DD.MM.YYYY and the time format is HH:MM:
Changing the Firefox browser language setting to Lithuanian displays the dates and times using the format YYYY-MM-DD and HH:MM respectively:
The automatic locale-specific formatting and parsing for date, time, and date/time controls can be configured by manually adding the following properties in the locale properties file:
For example, let's say you want to change the MM.DD.YYYY to display as "Day of the week, Month Day, year" in the German locale. Simply add the following to the ger locale file located in the WEB-INF/data/locale directory as explained above:
After replacing the /WEB-INF/data directory file with the updated one, the date will display as shown in the Firefox browser set for the German locale:
The Date picker will be automatically translated according to the browser locale. You can override the browser setting by adding the properties shown below to the locale file. This localization only applies to the date picker on the desktop as the native date picker will be shown on mobile devices. You can translate (locale-specific) month names and abbreviated day of week names (two characters). The days of the week will always be shown as Sunday through Saturday, left to right on the date picker. Only the Gregorian calendar system is supported.
To localize the date picker on the desktop, manually add the following properties in the appropriate locale properties file in the WEB-INF/data/locale directory as explained above.
For example, Let's say you add the properties below to a Chinese translation file named zh:
After replacing the modified /WEB-INF/data directory file, restarting and setting the Firefox browser to Chinese - zh, the date picker will display as shown in the image:
Notice the month is displayed as JaC and the days of the week show Mc, Tc, Wc and Tc for Sunday - Wednesday as specified by the format properties we added to the locale file. Thursday, Friday, and Saturday display in Chinese - the language setting of the browser in this example.
Entries for the Today and Close buttons on the Date Picker are already included in the default locale file so all you need to do is add your translations for them in the locale file you are going to use.
Internationalization of Date Picker for iOS.
The locale of the date picker on the safari browser changes with the iPhone/iPad's "Region Format" settings, not the language settings. After setting the language in iOS, set the appropriate country/region format in the iPhone general settings.
Navigate these settings to change the Country/Region Format on iOS devices: General>International>Region Format: Select the Appropriate Country.
You can add support for International characters for a form's Print view and submission PDFs by adding Unicode fonts with broad language support to the war file. Refer to this documentation for the details.
The Task list and workflow designer are not fully translated - they will be completed in a future release.
Since the form language is dictated by the URL locale parameter, you can allow users to switch the form language on demand using a link control in your form. Take the form's Raw Share URL (no iframe), append the desired locale, and put it in a Link Control. On the Link Control properties, uncheck "New Window" so the existing browser tab will refresh. When the user clicks the link, the form will reload with the locale parameter in the URL and the form in the translated state. It is important to note that reloading the form in this way will erase any existing data entered. Consider using a business rule to prevent the user from filling out any data until they've selected a language.
In this simple example we have added two link controls:
We've also set the control to disabled by default and added a trigger named 'BeginForm'. When the trigger is clicked, the language links and the trigger itself become hidden, and the control becomes enabled.