DR-000012 - Localization parameter for back-end

Submitted Date	Jun 9, 2021
Approved Date	Sep 7, 2021
Status	ACCEPTED
Impact	MEDIUM

Overrides/Supersedes

This decision was migrated from the Tech Leads Decision Log as part of a consolidation process. The original decision record can be found here.

RFC

N/A

Stakeholders

All Backend Developers

Contributors

@Julian Ladisch

Approvers

This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.

Background/Context

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://folio-org.atlassian.net/wiki/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

FOLIO-3196 - DECISION: Localisation parameter for back-end CLOSED

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

STRIPES-750 - DECISION: Which module should host back-end translation files? CLOSED , and then by the Tech Council on 2021-06-09 and 2021-06-16.

Assumptions

N/A

Constraints

N/A

Rationale

N/A

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.

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.

Implications

Pros
- N/A
Cons
- N/A

Other Related Resources