Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

  

Section
Column
width0px
 

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  (In-house only)

Translations use UTF-8 encoding by default but you may also upload ISO-8859-1 (Unicode) strings.

You can easily localize any form by clicking on the icon next to any form on the Forms Home Page. This open the Locale 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 above 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.

Column
width240px

On this page:

Table of Contents
maxLevel2
 

...

note
Code Block
Save\ failed.\ Status=
Save\ successful=
Save\ this\ form=
Saving=
Section\ A=
Sign\ this\ section=
load=
save=

Translation Considerations

  • Some browser have problems with apostrophe characters. Internet Explorer 8 is one such browser. To ensure that your translations are ok on all browsesr you should use the html escape character in place of the apostrophe.

...

Code Block
# Do NOT DO THIS on IE8
Initializing\ form=l'initialisation de la forme
# Instead use the html apostrophe escape sequence like this
Initializing\ form=l'initialisation de la forme 

...

 

  • Messages formatted in HTML that contain new line characters in the text may not translate properly. For Example, the Text "Trip Itinerary <br/> Please Complete" in a message control to label the Trip Intinerary section of the Travel Request form will appear on the screen to have a new line in it. New Lines are

...

  • ignored by HTML. Do not use new lines in forms that require localization.
  • 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.

  • The  Preview function displays in the default locale. This is as designed. Go to the existing internationalize page to test the use mode form in the target locale/language. 
  • Be careful when internationalizing markup. Do not assume that the string property name is valid markup. For Example: Let's say you had a field called FirstName in your form with this stying applied to the label: <span style="color:red;font-weight:bold;">FirstName</span>. The default strings properties file shows the property name as: <span\ style"color:red;font-weight:bold;">FirstName</span>. It is missing the '=' after style.  This is intentionally stripped out because otherwise if it was left in, the = would be interpreted as the end of the property name. Adding <span style="color:red;font-weight:bold;">Primero Nombre</span> to the right side of the "=" sign, in this case, will translate this label successfully. If you see the error message " Failed to generate PDF snapshot: Could not generate PDF" check the markup in your translation files.
Section
Column
width50%

Image Added

Column
width50%

Image Added

Upload and Test

Upload your translation file.

...

Your form's style (colors, font, etc...) can be locale specific. This enables the form designer to select culturally appropriate colors based on the current locale and to match forms to websites that have also been localized using cultural fonts and colors. See locale specific themes  for full details. 

International Characters for Print View and Submission PDFs

You can add support for International characters for a form's Print view and submission PDFs using a custom theme. Refer to this documentation for the details.