fix: normalize "original" locale to "en" for datetime formatting

[leonardthethird]

Fix datetime strings being partially localized based on OS language when site is in "Untranslated" mode.

When users select "Untranslated" mode, the locale is set to "original" which is not a valid BCP 47 tag. Browser Intl APIs fall back to OS language, causing mixed-language strings like "Revealed el próximo mes".

Adds a normalizeIntlLocale() utility that maps "original" to "en" and applies it consistently across all components using Intl-based date formatting.

Fixes #4122

Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved localized date and relative-time rendering by normalizing the “original” locale consistently across timestamp and “relative” displays.
  • Updated reveal times and upcoming content timestamps to use consistent locale-aware formatting.

• Refactor

  • Standardized date and distance formatting to route through shared internationalization helpers for consistent output.

• Chores / Style

  • Added lint guidance to prevent direct usage of lower-level date-fns Intl helpers in favor of the shared formatter utilities.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Date formatting utilities now normalize the original locale and provide shared Intl wrappers. Related components use those wrappers, RelativeTime normalizes its language attribute, and ESLint prevents direct Intl imports from date-fns.

Changes

Locale-normalized formatting

Layer / File(s)	Summary
Formatter helpers front_end/src/utils/formatters/date.ts	Adds locale normalization and shared date/distance Intl wrappers, and applies normalization to existing formatters.
Component call sites front_end/src/components/consumer_post_card/upcoming_cp.tsx, front_end/src/components/cp_reveal_time/cp_reveal_time.tsx, front_end/src/components/ui/relative_time.tsx	Updates relative and reveal-time rendering to use shared formatters and normalized language values.
Lint restriction front_end/eslint.config.mjs	Blocks direct date-fns Intl imports outside the formatter utility.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: ncarazon

Poem

A rabbit hops through dates so bright,
Making “original” English-right.
Shared wrappers guide each ticking time,
While lint keeps imports in line.
“Revealed soon!” the bunny sings,
With tidy locale-colored wings.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the main change: normalizing the "original" locale to English for Intl-based datetime formatting.
Linked Issues check	✅ Passed	The changes address #4122 by normalizing "original" to "en" for Intl date/time rendering, preventing OS-language fallback in Untranslated mode.
Out of Scope Changes check	✅ Passed	The ESLint restriction and formatter helper updates are directly tied to the locale-normalization fix and do not appear unrelated.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/issue-4122-some-feed-tile-text-inconsistently

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

front_end/src/utils/formatters/date.ts (1)

192-198: Add a small regression test around normalizeIntlLocale.

This helper is now the single guard for Untranslated mode, so a focused test for "original" -> "en" plus one passthrough locale would make the bugfix harder to regress.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@front_end/src/utils/formatters/date.ts` around lines 192 - 198, Add a small
unit test suite for normalizeIntlLocale: import normalizeIntlLocale from its
module, then add two tests — one asserting normalizeIntlLocale("original")
returns "en" and another asserting normalizeIntlLocale("fr") (or "en-US")
returns the same input (passthrough). Use the project's test framework (e.g.,
Jest) and place the test alongside other utils tests so it runs in CI; name the
tests clearly like "returns en for 'original' (Untranslated mode)" and "passes
through valid locales".

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@front_end/src/utils/formatters/date.ts`:
- Around line 192-198: Add a small unit test suite for normalizeIntlLocale:
import normalizeIntlLocale from its module, then add two tests — one asserting
normalizeIntlLocale("original") returns "en" and another asserting
normalizeIntlLocale("fr") (or "en-US") returns the same input (passthrough). Use
the project's test framework (e.g., Jest) and place the test alongside other
utils tests so it runs in CI; name the tests clearly like "returns en for
'original' (Untranslated mode)" and "passes through valid locales".

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 7c986d69-6129-4fac-b08b-7fe3c66e37ad

📥 Commits

Reviewing files that changed from the base of the PR and between 2e79b4d and e30cc43.

📒 Files selected for processing (5)

• front_end/src/app/(main)/(home)/components/research_and_updates.tsx
• front_end/src/components/consumer_post_card/upcoming_cp.tsx
• front_end/src/components/cp_reveal_time/cp_reveal_time.tsx
• front_end/src/components/ui/local_daytime.tsx
• front_end/src/utils/formatters/date.ts

[github-actions]

🚀 Preview Environment

Your preview environment is ready!

Resource	Details
🌐 Preview URL	https://metaculus-pr-4472-claude-issue-4122-some-feed-ti-preview.mtcl.cc
📦 Docker Image	ghcr.io/metaculus/metaculus:claude-issue-4122-some-feed-tile-text-inconsistently-1de58ab
🗄️ PostgreSQL	NeonDB branch preview/pr-4472-claude-issue-4122-some-feed-ti
⚡ Redis	Fly Redis mtc-redis-pr-4472-claude-issue-4122-some-feed-ti

Details

• Commit: 1de58abe5a887a93abd25b17b13e921e48aa7bda
• Branch: claude/issue-4122-some-feed-tile-text-inconsistently
• Fly App: metaculus-pr-4472-claude-issue-4122-some-feed-ti

---

ℹ️ Preview Environment Info

Isolation:

• PostgreSQL and Redis are fully isolated from production
• Each PR gets its own database branch and Redis instance
• Changes pushed to this PR will trigger a new deployment

Limitations:

• Background workers and cron jobs are not deployed in preview environments
• If you need to test background jobs, use Heroku staging environments

Cleanup:

• This preview will be automatically destroyed when the PR is closed

[leonardthethird]

@claude deal with failing unit tests / frontend checks.

[claude]

Claude finished @leonardthethird's task in 1m 35s —— View job

---

Fixed failing frontend lint check

• Identify failing CI checks — Frontend Checks failed at check linters step
• Read relevant code and test files — ESLint import/order error in research_and_updates.tsx
• Fix the failures — moved normalizeIntlLocale import into correct alphabetical position within the @/ import group
• Push fixes — committed and pushed as 930360b

Root cause: The normalizeIntlLocale import was placed in its own separate group (with a blank line above it) and was out of alphabetical order relative to other @/ imports. Fixed by removing the blank line and moving the import after @/utils/core/cn.
|

[ncarazon]

@claude can you resolve merge conflicts with main branch?

[claude]

Claude finished @ncarazon's task in 10m 5s —— View job

---

Merge conflict analysis

I can't perform the actual merge in this environment (both git fetch/git merge/git checkout <ref> -- ... and gh api are permission-gated here, and origin/main is shallow-cloned so there's no reachable merge base), so I've reconstructed what the conflicts are by comparing this branch's HEAD, the pre-PR base (2e79b4d), and the origin/main snapshot we have (eca63e3).

Conflict inventory

Only three files really matter — the rest of main's ~964 changed files are additions/edits our branch never touched, so git will auto-take main's version there.

1. front_end/.eslintrc.json — delete/modify

Main removed the legacy JSON config and switched to flat config (front_end/eslint.config.mjs). This PR modified .eslintrc.json to add the no-restricted-imports rule for date-fns intlFormat/intlFormatDistance. Standard resolution: delete .eslintrc.json on our side (accept main's deletion) and port the rule into eslint.config.mjs.

2. front_end/src/app/(main)/(home)/components/research_and_updates.tsx — delete/modify

Main deleted the whole file (the homepage was restructured — a batch of (home)/components/* files went away). This PR modified it to use formatIntlDate. Resolution: accept main's deletion.

3. front_end/src/components/consumer_post_card/upcoming_cp.tsx — text merge (non-overlapping)

Main changed <span>{t("cpRevealed")} </span> → <span className="block">{t("cpRevealed")}</span>. This PR changed the intlFormatDistance call to formatIntlDistance. Different lines — git will 3-way merge cleanly.

The other four PR files (cp_reveal_time.tsx, local_daytime.tsx, relative_time.tsx, utils/formatters/date.ts) weren't touched on main since 2e79b4d, so no conflicts.

The eslint.config.mjs wrinkle (worth calling out before you merge)

Porting the no-restricted-imports rule into eslint.config.mjs needs to happen as part of the merge commit itself. If I pre-add eslint.config.mjs on this branch with the rule baked in, git sees "both branches added this file with different content" at merge time — that's a fresh add/add conflict. The only clean path is: perform the real merge, and while resolving, append the restricted-imports block to the incoming eslint.config.mjs.

Suggested local sequence

git fetch origin main
git checkout claude/issue-4122-some-feed-tile-text-inconsistently
git merge origin/main
# Conflicts to resolve:
git rm front_end/.eslintrc.json
git rm 'front_end/src/app/(main)/(home)/components/research_and_updates.tsx'
# Then hand-edit front_end/eslint.config.mjs to append inside the existing rules block:
#   "no-restricted-imports": ["error", { "paths": [{
#     "name": "date-fns",
#     "importNames": ["intlFormat", "intlFormatDistance"],
#     "message": "Use formatIntlDate / formatIntlDistance from @/utils/formatters/date so the 'original' locale (Untranslated mode) is normalized for Intl APIs."
#   }]}],
# ...and add an ignores/override entry for src/utils/formatters/date.ts so it can still import the raw date-fns Intl functions.
# upcoming_cp.tsx should merge automatically — verify the block class + formatIntlDistance both survive.
git commit
git push

If you'd prefer, I can push a partial resolution that just deletes .eslintrc.json and research_and_updates.tsx — that unblocks the auto-merge but loses the ESLint guard rail (which you'd want to re-add in a follow-up commit against eslint.config.mjs once main's version is on the branch). Let me know and I'll go ahead.

• Fetch origin/main and check for conflicts (partial — shallow clone limited scope)
• Identify conflicting files
• Report resolution plan
• Push merge commit — blocked; needs local run or explicit go-ahead for the lossy partial fix
  • branch: claude/issue-4122-some-feed-tile-text-inconsistently

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@front_end/eslint.config.mjs`:
- Around line 73-76: Update the custom ESLint error message in the import
restriction containing importNames ["intlFormat", "intlFormatDistance"] to
recommend the actual exported helpers formatDate and formatRelativeDate instead
of formatIntlDate and formatIntlDistance. Preserve the existing guidance about
normalizing the “original” locale.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 6efcfa78-36e0-4aa7-af70-15e7eead629c

📥 Commits

Reviewing files that changed from the base of the PR and between ffa75a8 and 14b5210.

📒 Files selected for processing (1)

• front_end/eslint.config.mjs

[ncarazon]

@claude Run Unit Tests pipeline has failed. Looks like there are formatting errors. Could you please address it?

[claude]

Claude finished @ncarazon's task in 2m 2s —— View job

---

Fixed prettier formatting error in Run Unit Tests

• Check CI status — Frontend Checks > check formatting step failed on src/utils/formatters/date.ts
• Download job log and reproduce locally with bun run format:check
• Run prettier --write on the file and verify the diff
• Confirm all frontend files now pass prettier --check
• Push fix — 8781c8f

What was wrong: In formatIntlDate (date.ts:207-217) the third argument to intlFormat was written as a single-line object across multiple lines ({ locale: normalizeIntlLocale(locale) }), which prettier reformats to a multi-line object with a trailing key on its own line. One-file, cosmetic-only change.

-  return intlFormat(
-    date,
-    formatOptions ?? {},
-    { locale: normalizeIntlLocale(locale) }
-  );
+  return intlFormat(date, formatOptions ?? {}, {
+    locale: normalizeIntlLocale(locale),
+  });

CI should go green on the next run.
• branch: claude/issue-4122-some-feed-tile-text-inconsistently

[SylvainChevalier]

@claude please merge.

[claude]

Claude finished @SylvainChevalier's task in 23s —— View job

---

Unable to merge this PR

I'm not able to merge pull requests — my GitHub App permissions don't include branch operations (merging, rebasing, force-pushing). This is a deliberate safety restriction; see the FAQ for details.

The PR is approved by @ncarazon and CI is passing, so you (or any maintainer) should be able to hit the Merge pull request button directly, or from the CLI:

gh pr merge 4472 --squash   # or --merge / --rebase, whichever matches this repo's convention

If you'd like me to do something else on this branch first (rebase onto latest main, respond to a review comment, tweak the code), just say the word.
• branch: claude/issue-4122-some-feed-tile-text-inconsistently