Refactor translation system to be reusable in non-Astro code #1003
Conversation
🦋 Changeset detectedLatest commit: bd048d1 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. |
size-limit report 📦
|
| @@ -26,6 +27,7 @@ export default function StarlightIntegration(opts: StarlightUserConfig): AstroIn | |||
| name: '@astrojs/starlight', | |||
| hooks: { | |||
| 'astro:config:setup': ({ config, injectRoute, updateConfig }) => { | |||
| const useTranslations = createTranslationSystemFromFs(userConfig, config); | |||
There was a problem hiding this comment.
This variable is not in use yet, but would be passed into anything that needs it, such as the Starlight integration added in #742.
| /** | ||
| * Get the BCP-47 language tag for the given locale. | ||
| * @param locale Locale string or `undefined` for the root locale. | ||
| */ | ||
| function localeToLang( | ||
| locale: string | undefined, | ||
| locales: StarlightConfig['locales'], | ||
| defaultLocale: StarlightConfig['defaultLocale'] | ||
| ): string { | ||
| const lang = locale ? locales?.[locale]?.lang : locales?.root?.lang; | ||
| const defaultLang = defaultLocale?.lang || defaultLocale?.locale; | ||
| return lang || defaultLang || 'en'; | ||
| } |
There was a problem hiding this comment.
I’ve duplicated this function for now from slugs.ts:
starlight/packages/starlight/utils/slugs.ts
Lines 31 to 39 in ba70635
We could refactor in a similar spirit to make this version the base and then have a module that exports the easier to use methods that depend on virtual:starlight/user-config.
There was a problem hiding this comment.
Our base useTranslations() method is unchanged but is refactored to use the new createTranslationSystem() factory, passing in files loaded with getCollection().
* main: (22 commits) fix(docs-i18n-tracker): update `translations` import (withastro#1025) [ci] format i18n(zh-cn): Update css-and-tailwind.mdx (withastro#1018) [ci] format i18n(zh-cn): Update authoring-content.md (withastro#1016) i18n(ko-KR): update `configuration.mdx` (withastro#1015) i18n(ko-KR): update `sidebar.mdx` (withastro#1014) i18n(ko-KR): update `i18n.mdx` (withastro#1013) [ci] format i18n(ko-KR): update `frontmatter.md` (withastro#1017) [ci] format i18n(pt-BR): Update `css-and-tailwind.mdx`, `authoring-content.md` and `overrides.md` (withastro#1009) [ci] format [ci] release (withastro#996) Fix Prettier-compatibility of i18n test fixture Refactor translation system to be reusable in non-Astro code (withastro#1003) Add social icons to mobile menu footer (withastro#988) [ci] format Add Galician language support (withastro#1004) feat: add support for light / dark hero images (withastro#280) ...
What kind of changes does this PR include?
Description
getCollection()calls (for modules loaded by Astro) or file system calls (for modules running before Astro starts).useTranslationsto code that needs them (i.e. the Expressive Code integration and the asides plugin)To-do
Background
This is needed because our current i18n system depends on two bits of code that are only available after Astro starts:
getCollection()imported from theastro:contentvirtual module is used to load thei18ndata collection and get any user-configured JSON dictionaries of strings and Starlight user config imported fromvirtual:starlight/user-config.These dependencies prevented pre-Astro code like remark/rehype plugins or other integration code from accessing our translation system. So far, when trying to support i18n in those cases, we either got stuck or ended up making a copy of our i18n logic that didn’t cover all cases. This refactor helps make sure we share as much logic as possible between the code that runs before and after Astro starts.