For multi-language catalogs, you may want to filter results by language, that is, display results that use a subset of the languages you support. The response language restricts the search results to products and SKUs in a specific language. For example, if the response language is English, and the search text is “dress,” your results could include a number of sundresses as well as formal gowns, all of which are described in English.
There are two ways to structure a localized catalog. You can define one asset per product/SKU with properties representing different languages, or several assets per product/SKU, each in a different language. Regardless of the structure you use, the process of indexing produces the same document output, that is, one document for each language-to-product/SKU combination.
When you specify response languages, you can include any number of languages as long as those languages are specified in the search index. Unsupported response languages are ignored by ATG Search. If all response languages that you define are unsupported, ATG Search discards the language filter, returning all results that match the input settings.
There are two places to set response languages, one for search text and another for category. When a test includes search text and a category, the search text language is used. It’s a good idea to provide the same languages to both the category and search text response language settings. Search text response languages are applied to all tests that include search text, even those for which a category and a category response language have been provided. The category response language, in this case, is ignored.
Adding Search Text Response Languages
You can explicitly provide search text response languages, but if you don’t, ATG Merchandising uses the language a user selects from the Search Text Language drop-down list, which means that you’ll see only the products and SKUs that are indexed in the same language as the search text. A search for “robe” when the search text and search text response languages are English will return the silk and terrycloth coverings that one wears over pajamas.
Because you can specify one search text language at a time, if you want a test to find products and SKUs in multiple languages, you should specify multiple response languages. Consider a multi-language sporting equipment store. A search for “Specialized” reveals all Specialized bicycles sold by the store, which is helpful when each language catalog sells a unique set of SKUs.
Another reason to specify search response languages explicitly is if your site supports multiple languages and you’d like to search in one, but see results in another, perhaps more familiar language. For example, a French-speaking merchandiser, who wants to see “robes” from the English catalog, but doesn’t know that in English they are called dresses could search for “robe” when the search text language is French and the response language is English to see baby dolls, a-lines, among other dresses sold on the English-language site.
To specify response languages, you provide the languages to the Parser Options component as described in the following procedure. The procedure instructs you to create a properties file; however, if you prefer to use the ACC, select the corresponding components of class atg.search.routing.utils.Language instead of providing locales to targetLanguages.
Create a properties file for the Parser Options component with a
targetedLanguagesproperty set to a comma-separated list of languages or locales that represent the languages you want to support:$class=atg.search.routing.command.search.ParserOptions
$scope=requesttargetLanguages=en_US,en_GBSave the properties file to the local configuration directory as follows:
If you already have a Parser Options component, name this properties file for that component, and save it to the same location.
Otherwise, create a new component by naming the file anything you choose and saving to a directory, such as:
<ATG9dir>/home/localconfig/atg/commerce/searchIf you’ve created your own Parser Options component, you also need to add it to the
parserOptionsproperty of the Query Request component, which you find by checking thesearchRequestproperty of/atg/commerce/search/testing/SearchTestingQueryFormHandlerfor the name and location of the Query Request component.
For more information on the form handler class and Parser Options component, see the Search Form Handlers chapter of the ATG Commerce Search Guide.
Adding Category Response Languages
Category response languages are applied for tests that include a category as an input and not search text. Search Testing should support the exact same languages as your production site, if you want the complete set of results returned by the search engine to be visible in Search Testing. Note that it’s unlikely a site visitor would see all of those results, because most sites are coded to filter out results that aren’t in a site visitor’s language. If you’d like for Search Testing to display what a given site visitor sees, or results in a subset of the supported languages, specify those languages directly. Otherwise, copy your response language settings from your production site to see results in all languages.
Viewing Results in All Languages
To display results in all languages supported by your production site:
Copy all components of the following classes that exist in the production environment:
atg.search.routing.command.search.StringConstraint
atg.search.routing.command.search.ConstraintsGroup
atg.search.routing.command.search.ConstraintsGroupCopy the value in the
documentSetConstraintsproperty of the production Query Request component to the corresponding component in/atg/commerce/search/catalog.
Viewing Results in a Subset of Languages
The way in which you provide category response languages that are a subset of those supported by the production environment depends on the number of languages you want to use.
To view results in a single language, follow the steps in this procedure, which specify support for English:
Create a properties file for a component of class
atg.search.routing.command.search.StringConstraintas follows:$class=atg.search.routing.command.search.StringConstraint
$scope=request
property=language
operation=equal
value=EnglishSave the properties file in a Search Testing directory in your local configuration layer, such as
<ATG9dir>/home/localconfig/atg/commerce/search.Register the new component with the Query Request component in
/atg/commerce/search/catalogby setting thedocumentSetConstraintsproperty to the type of constraint being used. For example:documentSetConstraints=/atg/commerce/search/StringConstraint
To view results in multiple languages that are a subset of the total list of languages supported for production, you need to create several components, one for each language you want to support. For example, to view results in French and English, follow these steps:
Create a properties file for an English String Constraint component of class
atg.search.routing.command.search.StringConstraintin a Search Testing directory in your local configuration layer, such as<ATG9dir>/home/localconfig/atg/commerce/search:$class=atg.search.routing.command.search.StringConstraint
$scope=requestproperty=language
operation=equal
value=EnglishIn the same location, create a similar component called French String Constraint with French as the language:
$class=atg.search.routing.command.search.StringConstraint
$scope=requestoperation=equal
property=language
value=FrenchIn the same location, create a Constraint Group component that will combine the constraints in the String Constraint components that you created.
$class=atg.search.routing.command.search.ConstraintsGroup
$scope=request
constraints=EnglishStringConstraint,FrenchStringConstraint
operation=orRegister the new component with the Query Request component in /atg/commerce/search/catalog by setting the
documentSetConstraintsproperty to the Constraints Group component being used. For example:documentSetConstraints=StringConstraint
