Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties


Submitted Dateyyyy-mm-dd

 

Approved Dateyyyy-mm-dd

 

StatusACCEPTED
ImpactTBDMEDIUM


 

Overrides/Supersedes 

When applicable, provide links to all DRs that this DR overrides or supersedes 

RFC 

Provide links to all relevant RFC'sThis 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

...

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

Background/Context

Explain the need that triggered the need for making a decision

Assumptions

List all assumptions that were made when making the decision

Constraints

List any constraints that lead us to make a certain decision

Rationale

Document the thought process, list reasons that lead to the final decision

Decision

Short summary of the decision goes here

Implications

...

  • Provide a link to RFC when applicable

...

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 Image AddedFOLIO-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 Image AddedSTRIPES-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