Localizing REST requests and responses

There are four possible ways in which you can localize a REST request. In order of preference, they are:
  • Set values for custom headers GW-Language and GW-Locale
  • Use the locale preference set on browser set by user
  • Set a value for header Accept-Languague
  • Use the browser default language and locale

Guidewire recommends that you use custom headers GW-Language and GW-Locale to localize a REST request if you also need to localize the request response. This is most likely the case if there is a REST request directly from a browser or otherwise on behalf of an actual person.

Be aware that:
  • The authenticated user in PolicyCenter can be a generic integration user that does not have a meaningful language or locale preference.
  • Often, it is not possible for a user to change the Accept-Language header value if the REST request originates from a browser.

Rules for locale processing

PolicyCenter uses the following rules in determining and processing the locale on a REST request.
Rule #1 - If set, GW-Language and GW-Locale determine the language and locale for processing the request from that point on
The GW-Language and GW-Locale headers need to map to a virtual language and locale code. This means that if the header language or locale code is more specific than a language or locale configured on the server, the server falls back to the more generic option. For example, if you specify en_GB, which does not exist on the server, then REST processing on the server uses en instead.
If your header specification does not match any virtual language or locale, REST processing uses the default server language or locale instead. If this does happen, PolicyCenter does not report that the header language or locale did not match a configured server language or locale.
Rule #2 - If present, header Accept-Language sets the language for processing the request prior to authenticating the user
REST processing only uses the value of Accept-Language to set the language prior to authenticating the user. It sets the language only for the request, not the locale. The Accept-Language header functions in a similar fashion to the GW-Language header in that it can be a virtual language as well.
Rule #3 - If GW-Language and GW-Locale are not set, use the authenticated user's preferences for language and locale
The authenticated user's preferences override the Accept-Language header, but not the GW-Language or GW-Locale headers. If there is no authenticated user, or the authenticated user has no configured language preference, REST processing uses the Accept-Language header to set the language for remainder of REST processing.