If a solution is localized, then it can be displayed in different languages, depending on the language setting of the mobile device. For example, if a solution is designed with English text strings, then English is considered to be the solution's default language). Now, if these strings have also been localized into Spanish (that is, translated into Spanish), then the solution will automatically be displayed in English on English-language devices and in Spanish on Spanish-language devices. The key to the selection is that the language setting of the mobile device must correspond to the code name of one of the solution's localization languages.
However, you can also let the user select the language of the solution without needing to change the language of the device. The Set Language action enables the solution to be restarted with a user-selected language. For example, the user can tap a button to change to a specific language if this action is triggered by a button click (see screenshot below, which shows an action to restart the solution in US Spanish). Another option is to let the user select a language from a dropdown list in a combo box.
Enter the language-country code (for example, es-US or fr-CH) or just the language code (for example, es or fr). If the action is triggered (to select a specific language), then the solution's language will be decided according to the cascading order given below.
1.If the solution contains a matching language-country (es-US or fr-CH) localization, then strings of this localization are used where these exist
2.If no matching language-country localization (es-US or fr-CH) exists for a string, then the localized language (es or fr) string is used—if one exists
3.If no language-country localization (es-US or fr-CH) or language localization (es or fr) exists for a string, then the default language of the solution is used for that string
Alternatively, use the default language of the mobile device. In this case, the language setting of the device determines what language from among the available localization languages will be used. The same set of cascading rules listed above applies.
The On Error option lets you define what should be done if an error occurs. Since the error handling can be precisely defined for this action, errors on such actions (that provide error handling) are treated as warnings—and not errors. The advantage is that you do not need to check errors on actions for which error handling has already been defined. The following error handling options are available:
•Abort Script: After an error occurs, all subsequent actions of the triggered event are terminated. This is the default action if an error occurs. If you wish to continue despite an error, select either the Continue or Throw option.
•Continue: Actions are not terminated. Instead, you can select what to do in either event: when there is no error (On Success), or when there is an error (On Error). For example, you might want to display a message box saying whether a page load was successful or not.
•Throw: If an error is detected, this option throws an exception that is stored in the Try/Catch action's variable. The Catch part of the Try/Catch action is used to specify what action to take if an error occurs. If no error occurs, then the next action is processed. See the section Try/Catch action for details.
MobileTogether extension functions
MobileTogether provides a range of XPath extension functions that have been specifically created for use in MobileTogether designs. Some functions can be particularly useful with specific actions. For example, mt-available-languages() returns the languages in which the solution is available and could, for example, be used with the Message Box action. If a function is especially relevant to this action, it is listed below. For a full list of extension functions and their descriptions, see the topic MobileTogether Extension Functions.