Skip to end of banner
Go to start of banner

Localization parameter for back-end

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Status

IN PROGRESS

StakeholdersAll back-end module developers
Outcome

In progress

Created date2021-06-09
Owner

Background

To translate messages it returns a back-end API needs to know the locale of the client.

Example message: "No item with barcode {itemBarcode} exists", for details see https://wiki.folio.org/display/I18N/How+To+translate+FOLIO

Example locale: de for German

Two ways to pass the current locale to a back-end API have been proposed:

  • accept-language HTTP header line
  • lang query parameter

For details see

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

While it may be possible that Stripes supports multiple ways to pass the locale FOLIO should agree upon a single way that all back-end modules should use.

This was discussed among front-end devs during multiple stripes-architecture meetings with conclusions in Unable to locate Jira server for this macro. It may be due to Application Link configuration. , and then by the Tech Council on 2021-06-09 and 2021-06-16.

Decision

  • Back-end modules shall read the HTTP Accept-Language header, as specified in RFC-7231 Section 5.3.5, to determine the desired locale of the response.
    • The value is case insensitive (e.g. de and DE are equivalent).
    • Multiple values may be present in a comma-separated list.
      • Values may use weights in the range 0-1 appended to each value to indicate preference.
      • Values without a weight shall be considered 1.0.
      • Values with equal weights shall be considered to be ranked in descending order of preference.
      • e.g. de, en-gb;q=0.8, en;q=0.7
    • Values may optionally include subtags (e.g. de-DE). 
  • The default value en-US will be used when a request lacks an Accept-Language header.
  • Unspecified functionality should follow established precedent, e.g RFC-4646 (tags for identifying languages), RFC-7231 (HTTP Accept-Language header), ISO 639-1 (two-letter language codes), etc.
  • No labels