When you organize configurations by language, a search configuration folder uses language as its dimension type. Assets nested in it, regardless of whether they are search configuration folders or search configurations, must specify a particular language. That way, the search configuration applied to a given site visitor depends on the language that user reads.
You need to specify the languages that appear in the General tab as dimension values for search configurations, base search configurations, and search configuration folders. The languages you see there can represent general languages (English, for example) or locales (en_US), which are specific versions of a language used in a given country. You can make search results appear one way for English speakers from the United States and another for English speakers from the United Kingdom, each represented by a different search configurations.
It is possible to use more general languages for some resources (English) and more specific (en_US) ones for others, but note that ordering of resources is significant. Placing a search configuration with a language of English above a search configuration with a locale of en_US prevents the second from being used, given that ATG Search always applies the first search configuration that’s a match for a site visitor and English is superset of en_US. It’s a good idea to use a consistent value format (all general or all specific), or, if you blend the two, place resources with more specific values higher in the tree.
When you specify the language values, you provide roughly one language (US_english, for example) for each resource that specifies a language value (search configuration folder). Keep in mind, however, that there’s an All Others dimension value that applies its search configuration settings for users with a language that’s not represented elsewhere.
In addition to defining the languages available as dimensions to search configurations and search configuration folders, you must also specify the languages available to a base search configuration. If a search configuration inherits settings from a base configuration, the assets don’t need to use the same language, but must not have conflicting languages. There may be a one-to-one relationship between the languages supported in each, but that’s not frequently true. The best implementations reuse base search configuration as templates for multiple search configurations. Using general languages on your base search configurations makes them more likely to be reused.
Consider the following situation: The tree begins with a Language search configuration folder that contains many search configurations, among them one for French speaking Canadians and another for French speaking Belgians. By creating a base search configuration with a French language (fr), it can be used by both search configurations (fr_CA, fr_BE). Again, keep in mind that a base configuration may use the Any language value, making it available to all search configurations.
To define the languages, you update component properties either by accessing the component in the ACC or providing a new properties file for the component in your local configuration directory:
Access the resource you want to use to update the
/atg/search/config/LanguageDimensionServicecomponent properties.To specify languages for base configurations, set the
localesproperty to the list of locales you want to support. For example:locales=en,frTo specify languages for search configuration folders and search configurations, set the
languagesMapproperty to a mapping of resource bundle key to locale. For example:languageMap+=\
americanEnglish=en_US,\
canadianEnglish=en_CA,\
britishEnglish=en_GB,\
canadianFrench=fr_ca,\
belgianfrench=fr_be,\To specify a default language, which will be used when the tree does not use language as a dimension, specify a language or locale to the
defaultLocaleproperty.
ATG Merchandising displays the names of the languages commonly associated to the locales you specify. For example, en_US and en_BG both display as English by default. If you’d like to provide other names for your locales, you can do so in a resource bundle, following these steps:
Create a resource bundle in
/atg/core/i18n/MultiBundleFormatterof your local configuration directory, if you haven’t already created a custom resource bundle there. See Working with Resource Bundles for information on custom resource bundles.For the base configuration languages, use this format:
atg.search.dimension.language.locale.<locale>=<display_name>For example:
atg.search.dimension.language.locale.en= English (US, CA & GB)
atg.search.dimension.language.locale.fr=French (CA & BE)For the search configuration and search configuration folder languages, use this format:
atg.search.dimension.LanguageDimensionService.<locale>=<display_name>For example:
atg.search.dimension.language.americanEnglish=English (US)
atg.search.dimension.language.canadianEnglish=English (CA)
atg.search.dimension.language.britishEnglish=English (GB)
atg.search.dimension.language.canadianFrench=French (CA)
atg.search.dimension.language.belgianFrench
=French (BE)
The resource bundle keys use a prefix (atg.search.dimension, by default) defined in the dimensionValueKeyPrefix property of the LanguageDimensionService component. If want to use a different prefix or no prefix in the resource bundle keys, change the prefix in both places.
Detecting a Visitor’s Language
A search configuration may be designed for Belgian French speakers, but how does ATG determine which visitors in fact want to be identified as French-speaking Belgians? The language appropriate for a visitor depends on the locale ATG detects for him or her.
Each site implements its own mechanism for finding a user’s locale. One site might select a locale from the HTTP header of the request. Another site might supply a Profile page in which the user specifies a locale that ATG saves as a user profile property. A third site might provide a Language Preference dropdown list on a home page, and when a user makes a selection, it’s appended to the request as a query parameter that is processed by a custom pipeline servlet. Most multi-language sites will be designed to incorporate a combination of these options, giving a priority to each.
