Globalization

In the context of Guidewire InsuranceSuite applications, globalization refers to the internationalization and localization aspects of system configuration. The system APIs can work with the globalization settings of your system. For details on how Guidewire InsuranceSuite applications support globalization, refer to the Globalization Guide.

Specifying language and locale in API requests

By default, system API calls return data in the format of the default language and locale of your ClaimCenter instance, as specified by the DefaultApplicationLanguage and DefaultApplicationLocale system parameters in config.xml. If your instance supports additional languages and locales, then you can construct API calls to request data in those alternative formats.

Callers can specify a preferred language and locale in the request header. Guidewire provides two header fields for this purpose, GW-Language and GW-Locale. The GW-Language field accepts an ISO 639-1 code designating the language, while the GW-Locale field takes the ISO 639-1 language code along with the ISO 3166-1 alpha-2 locale code, separated by an underscore.

For example, the ISO 639-1 language code for Japanese is ja, and the ISO 3166-1 alpha-2 locale code for Japan is JP. The following code block displays a request header with the GW-Language and GW-Locale fields set to Japanese language and locale, respectively:

GET /pc/rest/account/v1/accounts/pc:102? HTTP/1.1
Host: localhost:8180
GW-Language: ja
GW-Locale: ja_JP
Authorization: Basic c3U6Z3c=

Addresses and locales

The formatting of postal addresses can vary by country. ClaimCenter provides a flexible way to format addresses using the Address entity along with the State and Country typelists. In the system APIs, this address data is mapped to the Address schema found in the Common API.

The following table lists each Address property with its associated Guidewire Address entity field:

Address property GW entity mapping Description
addressLine1 Address.AddressLine1 First line of a street address
addressLine1Kanji Address.AddressLine1Kanji First line of a street address (in Japanese)
addressLine2 Address.AddressLine2 Second line of a street address
addressLine2Kanji Address.AddressLine2Kanji Second line of a street address (in Japanese)
addressLine3 Address.AddressLine3 Third line of a street address
area Address.State Country-specific administrative area, as defined in the State typelist
city Address.City City or locality
cityKanji Address.CityKanji City or locality (in Japanese)
country Address.Country Country code, as defined in the Country typelist
county Address.State Country-specific administrative area, as defined in the State typelist
department Address.State Country-specific administrative area, as defined in the State typelist
district Address.State Country-specific administrative area, as defined in the State typelist
do_si Address.State Country-specific administrative area, as defined in the State typelist
emirate Address.State Country-specific administrative area, as defined in the State typelist
island Address.State Country-specific administrative area, as defined in the State typelist
oblast Address.State Country-specific administrative area, as defined in the State typelist
parish Address.State Country-specific administrative area, as defined in the State typelist
postalCode Address.PostalCode Postal or zip code
prefecture Address.State Country-specific administrative area, as defined in the State typelist
province Address.State Country-specific administrative area, as defined in the State typelist
sortingCode Address.CEDEXBureau Sorting code (France only)
state Address.State Country-specific administrative area, as defined in the State typelist

Address locale configuration

While the Address schema supports a wide range of properties for locale-specific administrative areas, only one such property can be used in a given address. For example, an address cannot use both state and province properties. Furthermore, only one administrative area property is valid in an address, and this is determined by the country or territory of the address. Studio provides an address configuration file at configuration/config/Integration/i18n/addresses.i18n.yaml:

countries:
  . . .
  JP:
    name: Japan
    addressFields: addressLine1, addressLine1Kanji, addressLine2, addressLine2Kanji, addressLine3, city, cityKanji, prefecture, postalCode
    addressRequire: addressLine1, city, prefecture, postalCode
  . . .
  US:
    name: United States
    addressFields: addressLine1, addressLine2, addressLine3, city, county, state, postalCode
    addressRequire: addressLine1, city, state, postalCode
  . . .

The countries field contains a property for each country or region, the name of which is derived from the relevant ISO 3166-1 alpha-2 country code. The previous code block displays two such properties, JP and US, for Japan and the United States, respectively. Each country property contains the following fields and values:

  • name: The name of the region (typically country or territory)
  • addressFields: The address fields from the Address schema that can be included in an address for the country or region
  • addressRequire: The minimum subset of address fields that must be included in an address for the country or region

When starting the server, the addresses.i18n.yaml file is loaded, and its rules are applied to Address resources. The Address schema contains code that enables this functionality:

"Address": {
  "type": "object",
  "x-gw-extensions": {
    "discriminatorProperty": "country"
  },
  "properties": {
    . . .
    }
  }
}

In the previous code snippet, the x-gw-extensions.discriminatorProperty field is set to country. As a result, when setting the country property on an Address resource, the address fields associated with that country will be valid for that resource, and the fields not associated with the country will be unavailable.