OBPIH-7488 support localized date patterns by ewaterman · Pull Request #5485 · openboxes/openboxes

ewaterman · 2025-09-08T22:47:40Z

✨ Description of Change

Link to GitHub issue or Jira ticket: https://pihemr.atlassian.net/browse/OBPIH-7488

Description: As a part of the timezone fix, we're trying to narrow down to only a specific set of patterns that we use for displaying dates. In addition, we want each of these date formats to be localizable since different languages might display dates differently.

For example, in English we may want to display LocalDate fields like dd/MMM/yyyy but in Chinese we may want to display them like yyyy 年 MM 月 dd 日.

So this ticket does the following:

adds the new set of localizable date formats to message.properties
fixes a malformatted spanish locale date
modifies the existing g:formatDate taglib to support localizing dates
modifies the DateFormatterManager.format method to support localizing dates

Ultimately, to localize our fields we do:

Instant: DateFormatterManager.format(Instant) which calls TemporalAccessorDateTimeFormatter.format(Instant)
LocalDate: DateFormatterManager.format(LocalDate) which calls TemporalAccessorDateTimeFormatter.format(LocalDate)
Messages: MessageLocalizer.localize('x.y.z')

📷 Screenshots & Recordings (optional)

Here's a diagram of all the important classes involved:

ewaterman · 2025-09-08T22:49:33Z

grails-app/i18n/messages_es.properties

 default.dashboard.label=Tablero
 default.data.label=datos
-default.date.format=dd / MMM / aaaa hh\: mm\: ss
+default.date.format=dd/MMM/yyyy hh:mm:ss a z


while I was testing I noticed that the spanish message for the default date was looking weird. It actually wouldn't parse properly for me. "a" is "AM"/"PM" so I think this format was just wrong...

ewaterman · 2025-09-08T22:50:06Z

grails-app/i18n/messages.properties

+date.format.date.label=dd/MMM/yyyy
+date.format.dateTime.label=dd/MMM/yyyy HH:mm:ss
+date.format.dateTimeZone.label=dd/MMM/yyyy HH:mm:ss XXX
+date.format.time.label=MM/yyyy


These are the localizations for the new date formats. We should only need to override them for locales that want a different format.

But lets discuss what patterns we want to go with. These will display like:

01/Jan/2025 01/Jan/2025 00:00:00 01/Jan/2025 00:00:00 +01:00 00:00:00

Which I picked since that's what we already use throughout most of the app.

ewaterman · 2025-09-08T22:54:59Z

grails-app/taglib/org/pih/warehouse/DateTagLib.groovy

+                .withDisplayFormat(attrs.displayStyle || attrs.format ? null : DateDisplayFormat.GSP)
+                .build()
+
+        return dateFormatterManager.format(attrs.date, context)


This allows us to specify additional attrs when using <g:formatDate>. We shouldn't need to use these extra attrs very often but it gives us the flexibility to override behaviours as needed for any edge cases that we have

ewaterman · 2025-09-08T22:56:31Z

grails-app/taglib/org/pih/warehouse/LocalizationTagLib.groovy

+
+    // Use Grails' namespace because we're overriding the default behaviour and so that the tag lib
+    // is accessible automatically throughout the app.
+    static namespace = 'g'


I might revert this whole class. I wanted to standardize how we localize messages in general but it wasn't working with special characters while I was testing locally. TBD after testing my branch on a deployed environment.

ewaterman · 2025-09-08T22:58:27Z

src/main/groovy/org/pih/warehouse/core/date/DateDisplayStyle.groovy

+    DATE('date.format.date.label', DateTimeFormatter.ofPattern('dd/MMM/yyyy')),
+    DATE_TIME('date.format.dateTime.label', DateTimeFormatter.ofPattern('dd/MMM/yyyy HH:mm:ss')),
+    DATE_TIME_ZONE('date.format.dateTimeZone.label', DateTimeFormatter.ofPattern('dd/MMM/yyyy HH:mm:ss XXX')),
+    TIME('date.format.time.label', DateTimeFormatter.ofPattern('HH:mm:ss'))


The enum version of the dates in message.properties. We don't strictly need this class but I find it much nicer to be able to work with enums instead of hard coded strings. That way if we need to change the underlying labels we can do so without refactoring all the usages

ewaterman · 2025-09-08T23:01:15Z

src/main/groovy/org/pih/warehouse/core/date/DateFormatterContext.groovy

+ * Context object containing the configuration fields for formatting dates.
+ * For a majority of cases the default settings can be used and so this context object will not be required.
+ */
+class DateFormatterContext {


I just moved this class to its own file. The only addition is displayStyleOverride

ewaterman · 2025-09-08T23:04:12Z

src/main/groovy/org/pih/warehouse/core/localization/LocalizableMessage.groovy

+ * A simple wrapper class on a translatable message/label.
+ * Used to indicate that translations can be applied to the message.
+ */
+class LocalizableMessage {


I didn't end up using this class but I would like to keep it in since I eventually want to do some work towards standardizing our error messages and this would play a part in that. I'm imagining we have either a custom error class or a custom error message class that can hold a localized message and any other data we need.

ewaterman · 2025-09-08T23:07:36Z

src/main/groovy/org/pih/warehouse/core/localization/MessageLocalizer.groovy

+ * Translates messages into a specific locale.
+ */
+@Component
+class MessageLocalizer {


This is meant to standardize how we localize our messages in the app. We have a ton of different approaches and I didn't know which to choose when localizing dates for this PR so got fed up and decided to try to unify them all under one component. Eventually I'd like to unify our errors and GSPs to all localize via the same method so that we can remove the other approaches. That's a refactoring I'll save for a future date but this at least gives us a starting point

ewaterman · 2025-09-08T23:09:34Z

src/main/groovy/org/pih/warehouse/core/localization/LocaleDeterminer.groovy

+ * If you're trying to translate a message, use {@link org.pih.warehouse.core.localization.MessageLocalizer}.
+ */
+@Component
+class LocaleDeterminer {  // Note I wanted to call this LocaleResolver but that's already a Spring component


I noticed we had a ton of different ways that we resolved locales so I decided that I was going to bite the bullet and try to unify our behaviour.

I'll eventually add a flow diagram to this PR to demonstrate all the components that go into this change since I feel like it's hard to visualize them all. I figured a bunch of single purpose classes gives us better flexibility and testability than a single, massive class that does locale, localization, and messaging all in one place.

Eventually I want to refactor LocalizationUtil and all the other l10n related services as well but that'd be too much for one PR

ewaterman · 2025-09-10T19:10:18Z

grails-app/taglib/org/pih/warehouse/LocalizationTagLib.groovy

+
+import org.pih.warehouse.core.localization.MessageLocalizer
+
+class LocalizationTagLib {


This isn't currently used anywhere. I figured we'd want to experiment with the new messageLocalizer before applying it everywhere. Once we're comfortable that this flow works, we can switch the namespace of this class to 'g' and then everywhere that we have <g:message> will go through this taglib.

jmiranda · 2025-09-18T21:39:20Z

grails-app/i18n/messages.properties

+date.format.date.label=dd/MMM/yyyy
+date.format.dateTime.label=dd/MMM/yyyy HH:mm:ss
+date.format.dateTimeZone.label=dd/MMM/yyyy HH:mm:ss XXX
+date.format.time.label=HH:mm:ss


As i mentioned on the call last week (?), i would really like to keep these all under the default namespace in messages.properties.

default.date.format=dd/MMM/yyyy default.time.format=HH:mm:ss default.date.time.format=dd/MMM/yyyy HH:mm:ss default.date.time.timezone.format=dd/MMM/yyyy HH:mm:ss XXX

If that's going to cause too big of a change (since default.date.format has always been used to render the full datetime format) then we could preserve that by leaving it alone

default.date.format=dd/MMM/yyyy hh:mm:ss a z

and adding more context-specific formats

default.date.only.format=dd/MMM/yyy default.datetime.format=dd/MMM/yyyy HH:mm:ss default.datetime.timezone.format=dd/MMM/yyyy hh:mm:ss a z default.time.format=HH:mm:ss

and then adding more date formats in the future, as needed if codifying these became necessary.

default.date.expiry.format=MMM yyyy default.date.pretty.format=EEE, MMM dd, yyyy default.date.weekday.format=EEE default.date.mysql.format=yyyy-MM-dd default.date.filename.format.=yyyyMMdd default.datetime.filename.format=yyyyMMddHHmmss

support localized date patterns

d7d3d29

ewaterman self-assigned this Sep 8, 2025

ewaterman commented Sep 8, 2025

View reviewed changes

ewaterman requested review from SebastianLib, alannadolny, awalkowiak, jmiranda and kchelstowski September 8, 2025 23:11

ewaterman added 2 commits September 8, 2025 16:13

fix bad date format

09279a8

formatter tests, don't use LocalizationTagLib

96772c3

ewaterman commented Sep 10, 2025

View reviewed changes

add timezone tests

cb04f49

alannadolny approved these changes Sep 18, 2025

View reviewed changes

new line at end of files

9a2c481

ewaterman merged commit 01b2e5c into develop Sep 18, 2025
2 of 5 checks passed

ewaterman deleted the ft/OBPIH-7488-localized-date-patterns branch September 18, 2025 21:23

jmiranda reviewed Sep 18, 2025

View reviewed changes

This was referenced Sep 23, 2025

OBPIH-7489 React date picker and utils using date fns #5507

Merged

OBPIH-7488 fix date format l10n labels for new date styles #5508

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

OBPIH-7488 support localized date patterns#5485

OBPIH-7488 support localized date patterns#5485
ewaterman merged 5 commits intodevelopfrom
ft/OBPIH-7488-localized-date-patterns

ewaterman commented Sep 8, 2025 •

edited

Loading

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 8, 2025

Uh oh!

ewaterman Sep 10, 2025

Uh oh!

Uh oh!

jmiranda Sep 18, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		import org.pih.warehouse.core.localization.MessageLocalizer

		class LocalizationTagLib {

Uh oh!

Conversation

ewaterman commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✨ Description of Change

📷 Screenshots & Recordings (optional)

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jmiranda Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ewaterman commented Sep 8, 2025 •

edited

Loading

jmiranda Sep 18, 2025 •

edited

Loading