extract text to translation ready files -- Bill Detail Page

[jicruz96]

Summary

• closes Extract text to translation-ready files -- Bill Detail Page #955
• creates a wrapper of useTranslation (from next-i18next) to better handle localized date formatting (from date-fns)
  *Why? multiple areas require formatting dates according to the locale. this compartmentalizes the logic to a single spot.

Checklist

• On the frontend, I've made my strings translate-able.
• If I've added shared components, I've added a storybook story.
• I've made pages responsive and look good on mobile.

Screenshots

Note: You should notice no changes!

🖱️ Click to see screenshots

Known issues

how to display bills with no primary sponsor?

• see this comment

right spot for a translation util? (but it's nbd)

• Intuitively, the new translation utils would've gone in the existing components/translations.tsx file, but this file is actually a server-side rendering utility, so instead I've created a new file components/i18n.ts. Ideally, components/translations.tsx is renamed/moved elsewhere to better indicate its responsibility in SSR.

right spot for translations not super clear (but it's nbd)

• Whether or not the new translations should go under the existing common.json or a new json file is kind of an arbitrary decision. common.json has some bill stuff, but then other bill stuff have their own file (e.g. billSearch.json). Overall, not super important either way. I just went with dumping them in common.json.

Steps to test/reproduce

1. Go to bill search and sort by next hearing date.
2. Confirm that the following text looks as expected:
   • In bill search page:
     • "hearing scheduled for" in the billHit card.
     • "Sponsor: " info in billHit card.
       • make sure to check a few cases: no cosponsors, 1 cosponsor, several cosponsors...
     • "Committee: " info in billHit card.
   • In a bill detail page (any one with a hearing date)
     • "Bill Tracker" title in the bill detail page
     • all text in "Sponsors" card ("Sponsors", "Lead Sponsor", "See N Cosponsors") link.
       • "{{billId}} Cosponsors" in the cosponsors modal once you click "See N Cosponsors"
     • "Committee" title in committee maple card section.
     • "hearing scheduled for" in hearing date container next to Sponsors and Committees
     • table headers in status table once you click the bill status container ("Status & History", "Status", "Branch")

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
maple-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 7, 2025 5:20am

[jicruz96]

🪲 yo look out for this bug

During self-review, I became aware of one pre-existing bug that I did not fix but also made worse. Bills with only one sponsor don't look right in the bill hit.

Existing Bug

Notice the buggy appearance of the sponsors:

After

Now it says undefined instead which is arguably worse.

I can give it a try at fixing tomorrow. Does anyone how we should interpret sponsor lists if .primarySponsor is null ?

After Pt. 2

aight I fixed it now actually but I don't love it. what do y'all think?

[Mephistic]

Thanks for taking this on! A few comments:

how to display bills with no primary sponsor?

Let's check in with Matt Victor - I'm not actually sure what it means for a bill to have no primary sponsor, so it might be a data error. Your fallback seems reasonable if we don't have a better answer for why this would happen.

right spot for a translation util? (but it's nbd) Intuitively, the new translation utils would've gone in the existing components/translations.tsx file, but this file is actually a server-side rendering utility, so instead I've created a new file components/i18n.ts. Ideally, components/translations.tsx is renamed/moved elsewhere to better indicate its responsibility in SSR.

Seems sensible to me.

right spot for translations not super clear (but it's nbd) Whether or not the new translations should go under the existing common.json or a new json file is kind of an arbitrary decision. common.json has some bill stuff, but then other bill stuff have their own file (e.g. billSearch.json). Overall, not super important either way. I just went with dumping them in common.json.

As a general rule: Anything that's part of omnipresent or shared UI elements (e.g. the header/footer) belongs in common.json. Anything that lives on a specific page (e.g. the text on the "Submit Testimony" page) should go in a ***.json related to that page.

That said, we're not as strict about that as maybe we should be (partly because this process has involved updating a bunch of old code where it's not always easy to tell all the places where certain components are getting used).

[jicruz96]

@Mephistic ok I've removed components/i18n.ts. The wrapper was indeed unnecessary. Newest commits fully use i18next built-ins to handle date localization. Those changes obviated all of the open comment threads.

Let's check in with Matt Victor - I'm not actually sure what it means for a bill to have no primary sponsor, so it might be a data error. Your fallback seems reasonable if we don't have a better answer for why this would happen.

Talking to @mvictor55 today, he implied that there ought to always be a primary sponsor, falling back to the executive when there isn't a legisltive one, but that making sure we get this detail right in the data scrape is not a worthwhile endeavor right now. so since that is the case and since the codebase itself declares primarySponsor as a nullable value, and evidently there are times where it is null, I say we keep the fallback.

[Mephistic]

LGTM