Expose localized UI strings in route data

[delucis]

Description

• Closes Allow useTranslations in overridden components #1060 and also partially addresses Cannot access certain imports - Overriding components #860.
• Exposes a new labels property in Starlight’s route data object for each page.
• This object includes all localized UI strings that up to now were retrieved using useTranslations() and the t() helper it returned.
• This enables components overriding Starlight’s defaults to easily reuse the built-in UI strings.
• This PR also refactors all our built-in components to use labels instead of calling useTranslations() themselves.
• Removes the t.pick() helper previously returned by useTranslations() is it is no longer used.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6d9e44d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@astrojs/starlight	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

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

Name	Status	Preview	Updated (UTC)
starlight	✅ Ready (Inspect)	Visit Preview	Nov 29, 2023 7:24pm

[astrobot-houston]

size-limit report 📦

Path	Size
/index.html	5.12 KB (0%)
/_astro/*.js	20.11 KB (0%)
/_astro/*.css	13 KB (0%)

[HiDeoo]

The changes look good to me and I think this properly address the linked issues.

One thing I want to note tho is that with this approach, if we ever move to i18next or something similar with a more advanced t(), we would not be able to use some of the advanced features like interpolation, formatting, plurals, context, etc. I don't really see us needing those features in the near future, but I just wanted to point that out.

[delucis]

if we ever move to i18next or something similar with a more advanced t(), we would not be able to use some of the advanced features like interpolation, formatting, plurals, context, etc.

I think if we ever do that, we could still expose those functions on the route data object. Technically this API could have just added t() to the route data object, but I decided to go the plain data route because it fits better with the rest of our route data story for now.

[HiDeoo]

I think if we ever do that, we could still expose those functions on the route data object. Technically this API could have just added t() to the route data object, but I decided to go the plain data route because it fits better with the rest of our route data story for now.

Oh definitely, I meant "we would not be able to use some of the advanced features" while keeping the same API without additional changes like exposing t(). Should have been more clear about that, my bad.