Internationalization and Localization (UXPROD-779)

[UXPROD-3150] Allow for customizable date UI display Created: 29/Jun/21  Updated: 02/Dec/21

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Internationalization and Localization

Type: New Feature Priority: TBD
Reporter: Peter Murray Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by UX-400 UX Review of KWare's User-Level Local... In Progress
Epic Link: Internationalization and Localization
Development Team: None
PO Rank: 0
Rank: Cornell (Full Sum 2021): R2
Rank: GBV (MVP Sum 2020): R2

 Description   

Current situation or problem: The advantage of being able to select the date format of choice for each locale removes the previous restriction of having to use the hard-coded ISO date format (yyyy-mm-dd), as enforced in the Users app, or to use the default date format set by (moment.js) or (React- intl) libraries, including date strings viewing and editing.

In scope

Out of scope

Use case(s)

Proposed solution/stories

From UX-400:

!https://folio-org.atlassian.net/secure/thumbnail/32084/_thumb_32084.png!
 

Links to additional info

Questions

  1. Can this be done in the React International currently used by Stripes? Or will the locale date display functionality of React International need to be overridden to allow for the customization of the date display?


 Comments   
Comment by Peter Murray [ 30/Jul/21 ]

Massoud Alshareef: Does STCOM-860 Closed help with the date display issue? Also see the linked issues of the related FOLIO-3208 Closed .

Comment by attia.alshareef [ 02/Aug/21 ]

Hi, Peter Murray 
The issues STCOM-860, FOLIO-3208 helps to solve the problem of sending Hindu numbers to the backend and I am glad to know that the problem has been solved (by the way we have made temporary solutions for it in the past).
But it is a problem other than the one we are talking about here because we still need flexibility in choosing the appropriate date format for each locale according to what the tenant sees fit for it.
Also at the user level, we need such flexibility in choosing the date format and the shapes of the numbers (Arab or Hindu) instead of leaving the decision to the developers or localization libraries to determine them (as you mentioned in the description above).
And that's what we're trying to deliver with our UI language switcher widget.

Comment by Peter Murray [ 02/Aug/21 ]

Thank you for the details, Attia. Just for your information, the feature to change the display of dates (this issue) is different from the UI language switcher widget ( UXPROD-3149 Open ). As far as I understand the requirements and the code changes, the two are not intertwined. (One could be put in place without needing the other.)

Comment by attia.alshareef [ 03/Aug/21 ]

This depends on the scope of this issue (which has not yet been established).
For example, if we are talking here about enabling the tenant to choose the date format for each locale, they will be closely related because it will be from the same list of tenant available languages.
But if we are talking about stripes apps benefiting from the pre-selected date format for each locale through the list of tenant available languages, it is okay to separate the two from each other, which I see appropriate for this issue.

Comment by Peter Murray [ 04/Aug/21 ]

My understanding is that date formatting is controlled by React Int'l, and that changing this would require all modules to change the JavaScript that they use to render dates on the screen. If that isn't the case—if it just requires a change to Stripes core, say—then great! We can try to work it in. If not, a change like that is going to need to go through at least the tech leads for review, starting with a Design Decision proposal.

Still, I think it makes sense to concentrate on one or two changes to Stripes core ( UXPROD-3148 Open and UXPROD-3149 Open ) rather than trying to do too much.

Generated at Fri Feb 09 00:29:44 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.