-
-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for translating sidebar badges #2285
Add support for translating sidebar badges #2285
Conversation
🦋 Changeset detectedLatest commit: dc863a8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
✅ Deploy Preview for astro-starlight ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Lunaria Status Overview🌕 This pull request will trigger status changes. Learn moreBy default, every PR changing files present in the Lunaria configuration's You can change this by adding one of the keywords present in the Tracked Files
Warnings reference
|
items: [ | ||
{ | ||
slug: 'constellations/andromeda', | ||
badge: { | ||
en: 'New', | ||
'pt-BR': 'Novo', | ||
}, | ||
}, | ||
{ | ||
slug: 'constellations/scorpius', | ||
badge: { | ||
text: { | ||
en: 'Outdated', | ||
'pt-BR': 'Descontinuado', | ||
}, | ||
variant: 'caution', | ||
}, | ||
}, | ||
], | ||
}, | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome stuff! Happy to add this.
I wonder if it would be simpler to only support localized strings using the text
property though? I find it a bit weird to have two config options that are objects but that mean very different things depending on what the keys are, i.e. one object is “record of locales to labels” the other is “precisely typed config object with known keys”. (Without testing, I’d guess this also interferes with IDE autocomplete?)
Also, imagine this badge:
badge: {
en: 'New',
fr: 'Nouveau',
}
If you decide you want to make it a success
variant, this doesn’t work:
badge: {
en: 'New',
fr: 'Nouveau',
+ variant: 'success',
}
So overall, I think I’m in favour of a single syntax rather than two. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial implementation was what you described, then I somehow managed to convince myself that if you were using the shorthand notation, you would prefer to use that too with translated labels. I ended up not liking it personally but couldn't decide if I should remove it or not.
If you're having the same feeling too, I'll be more than happy to remove it (and it'll make the implementation simpler). I'll update the PR accordingly. Thanks again for the great input 🙌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, yeah, going from badge: 'New'
to badge: { text: { en: 'New' } }
feels superficially like a lot, but I think in practice it’s OK and even it is slightly verbose, it definitely is clearer to explain/understand. Plus once you have a couple of locales the difference is kind of not so bad, e.g.
badge: { text: { en: 'New', fr: 'Nouveau', de: 'Neu', it: 'Nuovo' } }
// vs
badge: { en: 'New', fr: 'Nouveau', de: 'Neu', it: 'Nuovo' }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I second having only one config option with locales inside text
. It's a key longer but a very small price to pay to have localized badges 💜.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks you both, super appreciated. I have updated the PR accordingly, definitely an improvement 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks @HiDeoo — ready for the next minor 🫡
if (!defaultText) { | ||
throw new AstroError( | ||
`The badge text for "${itemLabel}" must have a key for the default language "${defaultLang}".`, | ||
'Update the Starlight config to include a badge text for the default language.\n' + | ||
'Learn more about sidebar badges internationalization at https://starlight.astro.build/guides/sidebar/#internationalization-with-badges' | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noting that one way to avoid needing this would be to use the same API we use for sidebar items themselves:
{
label: 'Andromeda',
translations: { fr: 'Andromède' },
}
I don’t have a strong opinion — we use the string | Record<string, string>
form for the site title, but the label
/translations
form here in the sidebar currently. I’m pretty sure I opted for the separate translations
property when designing the sidebar API to enforce the presence of a default label at the schema level, but having translations
keys proliferating everywhere also isn’t amazing.
Happy to keep this as is, but wanted to note this while approving!
Updated the test coverage thresholds in fd48b6b (no other changes since the approval) |
Description
This PR adds the ability to translate sidebar badges using the same approach as the site title. A badge text can be a string, or for multilingual sites, an object with values for each different locale.
This syntax is compatible with the string/object syntax to define badges. To support this feature, a new type of badge was added (
I18nBadge
) and can only be used in the sidebar configuration.