Internationalization and Localization (UXPROD-779)

[FOLIO-3196] DECISION: Localisation parameter for back-end Created: 09/Jun/21  Updated: 23/Nov/21  Resolved: 07/Sep/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None
Parent: Internationalization and Localization

Type: Tech Debt Priority: P2
Reporter: Julian Ladisch Assignee: Unassigned
Resolution: Done Votes: 0
Labels: i18n, translation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-371 Enable translation of validation and ... Open
Relates
relates to FOLIO-3351 Remove lang query parameter Closed
Sprint:
Development Team: None
Epic Link: Internationalization and Localization

 Description   

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

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

accept-language HTTP header line

This is a standard HTTP header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language

The FOLIO front-end doesn't use it in favor of a configuration setting for the reasons explained in https://www.w3.org/International/questions/qa-when-lang-neg.en

The back-end modules can be extended to use the accept-language HTTP header line to determine the language they need to translate into.

lang query parameter

FOLIO defines the lang query parameter in the language RAML trait: https://github.com/folio-org/raml/blob/raml1.0/traits/language.raml

lang:
  description: |
    Requested language. Optional. [lang=en]
  type: string
  required: false
  default: en
  pattern: "[a-zA-Z]{2}"

It is declared in all RAML resource types: https://github.com/folio-org/raml/tree/raml1.0/rtypes

Therefore most back-end APIs already have the (unused) lang parameter in their implementation, for example https://github.com/folio-org/mod-circulation-storage/blob/master/src/main/java/org/folio/rest/impl/ScheduledNoticesAPI.java

The trait pattern must be extended to allow for RFC5646=BCP47 language tags that are longer than two letters, FOLIO already have front-end translations with longer tags, for example es_419, es_ES, zh_CN, zh_TW. The pattern change is a non-breaking change.

Decision log entry

https://folio-org.atlassian.net/wiki/display/DD/Localization+parameter+for+back-end



 Comments   
Comment by Zak Burke [ 25/Aug/21 ]

Julian Ladisch, this ticket is cross-linked with a decision log entry and has been lingering on my to-do list for some time. Sorry!

As noted in the TC's minutes from 2021-06-09, we discussed using the HTTP request's Accept-Language header as the preferred implementation but did not commit to it. My recollection was that there was broad agreement among front-end devs, Tech Council members, and back-end devs that Accept-Language was a good choice. I have updated the Decision Log entry accordingly but left the status "In Progress" until I could confirm this with you. If you agree with the decision, please change the status to "Done".

If you disagree with the decision please let me know ASAP.

If you agree but think we need to provide additional information, let's plan a meeting but also consider changing the status to "Done" to indicate that the major decision has been made.

Thanks!

Generated at Thu Feb 08 23:26:19 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.