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 regionaddressRequire
: 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.