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 PolicyCenter 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. PolicyCenter 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 a
locale-based 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 locale, the name of
which is derived from the relevant ISO 3166-1 alpha-2 locale code. The previous code block
displays two such properties, JP
and US
, for
Japan and the United States, respectively. Each locale 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 localeaddressRequire
: The minimum subset of address fields that must be included in an address for the locale
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.