| Prev | Chapter�14.�Internationalization | Next |
|---|
+
This document describes how to develop internationalized OpenACS packages, including writing new packages with internationalization and converting old packages. Text that @@ -22,7 +22,7 @@ database must use internationalized functions. All displayed dates must use internationalized functions. All displayed numbers must use internationalized functions. -
OpenACS does not have a general system for supporting multiple, localized versions of user-input content. This document currently refers only to internationalizing the text in the package user interface.
+
Localizable text must be handled in ADP files, in TCL files, and in APM Parameters. OpenACS provides two approaches, message keys and localized ADP files. For ADP pages which are mostly @@ -32,7 +32,7 @@ which are static and mostly text, it may be easier to create a new ADP page for each language. In this case, the pages are distinguished by a file naming convention. -
If the request processor finds a file named filename.locale.adp, where locale matches the user's locale, it will process that file instead of filename.adp. For example, for a user with locale tl_PH, the file index.tl_PH.adp, if found, will be used instead of index.adp. The locale-specific file should thus contain text in the language appropriate for that locale. The code in the page, however, should still be in English. Message keys are processed normally.
+
OpenACS does not have a general system for supporting multiple, localized versions of user-input content. This document currently refers only to internationalizing the text in the package user interface.
If the request processor finds a file named filename.locale.adp, where locale matches the user's locale, it will process that file instead of filename.adp. For example, for a user with locale tl_PH, the file index.tl_PH.adp, if found, will be used instead of index.adp. The locale-specific file should thus contain text in the language appropriate for that locale. The code in the page, however, should still be in English. Message keys are processed normally.
Internationalizing templates is about replacing human readable text in a certain language with internal message keys, which can then be dynamically replaced with real human language in @@ -90,13 +90,14 @@
Typical static key lookup: [_ package_key.message_key] - The message key and package key used here must be string literals, they can't result from variable evaluation.
Static key lookup with non-default locale: [lang::message::lookup $locale package_key.message_key] - The message key and package key used here must be string literals, they can't result from variable evaluation.
Dynamic key lookup: [lang::util::localize $var_with_embedded_message_keys] - In this case the message keys in the variable var_with_embedded_message_keys must appear as string literals \#package_key.message_key\# somewhere in the code. Here is an example of a dynamic lookup: -
set message_key_array { + set message_key_array { dynamic_key_1 \#package_key.message_key1\# dynamic_key_2 \#package_key.message_key2\# } set my_text [lang::util::localize $message_key_array([get_dynamic_key])] -+ +
Translatable texts in page TCL scripts are often found in page titles, context bars, and form labels and options. Many times the texts are @@ -122,24 +123,26 @@ variables and or procedure calls in it you should in most cases try to turn the whole text into one message in the catalog (remember that translators is made easier the longer the phrases to translate are). In those cases, follow these steps: -
+ For each message call in the text, decide on a variable name and replace the procedure call with a variable lookup on the syntax %var_name%. Remember - to initialize a tcl variable with the same name on some line above the text.
If the text is in a tcl file you must replace variable lookups + (occurences of $var_name or ${var_name}) with %var_name%
You are now ready to follow the normal procedure and mark up the text using a tempoarary message tag (<#_ text_with_percentage_vars#>) and run the action - replace tags with keys in the APM.
+ replace tags with keys in the APM.
The variable values in the message are usually fetched with upvar, here is an example from dotlrn: -
+ ad_return_complaint 1 "Error: A [parameter::get -parameter classes_pretty_name] must have <em>no</em>[parameter::get -parameter class_instances_pretty_plural] to be deleted" -+ was replaced by: -
+ set subject [parameter::get -localize -parameter classes_pretty_name] set class_instances [parameter::get -localize -parameter class_instances_pretty_plural] ad_return_complaint 1 [_ dotlrn.class_may_not_be_deleted] -+ +
This kind of interpolation also works in adp files where adp variable values will be inserted into the message.
Alternatively, you may pass in an array list of the variable values to be interpolated into the message so that @@ -206,4 +209,4 @@
Developers are responsible for creating the keys in the message catalog, which is available at /acs-lang/admin/ -