SmCPW (change password interface), APSAdmin (help desk interface) and Forgot (part of the FPS interface) can infer the user's locality from information passed from the user's browser. The rules for determining the browsers language are:
If so, its value is the name of a cookie to use. The cookie should contain the desired language information using the same format as the HTTP accept-language header. It will be processed instead of the value of the accept-language header. No other responses or cookies are examined.
If so, their values indicate the actual ISO language and country codes to use. No additional processing will occur.
The resulting string (either from the cookie or the HTTP header) is evaluated from left to right to find a supported language/country combination. If any combination has full support (both language and country), it will be used, otherwise, the first value with a language only match will be used.
If no match can be found, US-EN will be used.
The default form that SmCPW builds uses translations for all prompts, window titles and messages. These all come from the SmCPW.lang file. To support multiple locales, copy the default SmCPW.lang file to each required locale (directory) and translate the messages for the appropriate language.
To modify a default in English, just modify the English language file.
Of course, your site can always use a custom form and handle the form localization yourself.
Error and confirmation messages used by SmCPW originate from either the SmCPW.lang file or the APS.lang file, depending on where the message actually originated. Just locate the desired message to translate and change it, either in the English language file or in the language appropriate for the change.
For all such error messages, regardless of where it originates, if it "looks" like a URL, SmCPW will redirect the user rather than displaying the message. Thus, you can do your own localization by redirecting messages to known Web Pages that do their own translation.
If you want to entirely do your own translation, you should set the SM_LANGUAGE and SM_COUNTRY responses for SmCPW to EN and US. Supply your own form (that adapts to the user's locality) and modify all of the EN-US message translations to URLs instead of text. In this case, SmCPW will display no messages itself, it will just redirect the user to pages that can adapt themselves. The full capabilities of SmCPW are detailed elsewhere in this document.
The forms that APSAdmin builds use translations for all standard elements, window titles and messages. These all come from the APSAdmin.lang file. To support multiple locales, copy the default APSAdmin.lang file to each required locale (directory) and translate the messages for the appropriate language.
Section labels and field prompts are specified in the [APSAdmin] section of APS.cfg and are not normally translated. If translation for these elements is desired, put a pound sign ("#") in front of the prompt definition in APS.cfg. This tells APSAdmin that the prompt should be translated. The key for translation is the full prompt value (including the "#") and the default translation has the "#" removed.
To modify a default in English, just modify the English language file.
|
Copyright © 2014 CA.
All rights reserved.
|
|