From CollectiveAccess Documentation
Revision as of 18:23, 1 August 2018 by Jonathan (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

CollectiveAccess supports localizations of its user interface. It also supports multi-lingual metadata - you can add information translated into many languages to a object or authority record. Whenever a language must be specified, either to indicate how the UI should be localized or what language metadata is in, a locale code is used.

Locale codes are comprised of a two or three character country code taken from the ISO 639 standard and a two character language code taken from the ISO 3166-1 standard joined together by an underscore ("_") character. For example, English as spoken in the United States is indicated by en_US. German as spoken in Germany is indicated by de_DE. An optional dialect specifier may also be added following the country and separated with an underscore when sub-divisions of languages must be taken into account. (Note: the dialect specification may be dropped in the future; if you think this should stay let us know.)

Locale-specific information in CA

Locale-related information is stored into three places within CA:

  • The list of locales for which CA can accept cataloguing is stored in the ca_locales table in the database. ca_locales records simply contain the language, country and dialect codes along with a unique, compact integer identifier that is used internally to represent the locale.
  • Localized text for the user interface is stored in GNU GetText-compatible .po files in the app/locale/<locale_code> directory (for example: app/locale/en_US). Note that not all locales present in the ca_locales table will have localization files in app/locale, but that all locales with localization files will have a corresponding record in ca_locales.
  • Configuration specifying how date/time expressions are parsed and presented for a given locale are stored in app/lib/core/Parsers/TimeExpressionParser When creating a new locale it is best to clone an existing locale file and alter it to suit the new locale.
  • CA uses Zend_Locale (from the Zend Framework) to manage other localization data (number formats, country and language names and the like). The data is stored in app/lib/core/Zend/Locale/Data in files using standard locale codes.

How locales are selected

Each CA user may select a preferred locale for their user interface; the list of locales is limited to those for which a user interface translation exists in app/locale. The selected locale is used not only for the user interface but also, when possible, for displayed content. That is, CA will always try to display catalogued data in the user's preferred UI locale. If catalogue data is not available in the user's selected language then CA will attempt to display the data using one of the system default locales, as set in the global.conf configuration file. The default locales will be used in order of listing until catalogue data is found. If no catalogue data exists for the default locales, the CA will display data in whatever locale does exist.

Translating CA into a new language

For information on how to translate CA into a language for which a translation does not yet exist see the Creating a Translation page.



Personal tools