Zenith Changelog
1.2.0 - 2025-04-26
New i18n features
You’ll find a new
getLocalizedRoute()
function as a drop-in replacement forgetRelativeLocaleUrl()
. This is more flexible as it utilizes therouteTranslations
object to auto-translate routes for you in components. You can use it like this:import { getLocaleFromUrl } from "@/js/localeUtils";import { getLocalizedRoute } from "@/js/translationUtils";const currLocale = getLocaleFromUrl(Astro.url);const route = getLocalizedRoute(currLocale, "/overview");// for the below routeTranslations, this would become "/fr/apercu" for FrenchAdjust existing i18n config script to account for additional features
1.1.0 - 2025-04-24
New i18n features!
New content collection localization capabilities, where individual blog posts in different languages can be linked with a
mappingKey
in the frontmatter. This allows content collections to be easily translated without needing to update therouteTranslations
object each time!- This is accomplished in the new
localizedCollections
object
src/config/translationData.json.ts /*** * Content collection translations used by the language switcher and hreflang generator** Per-collection, per-locale route base mapping (collections to localize are the keys)** If you have a key of "blog" then the blog content collection will be localized. This will look* for a "mappingKey" in the entry metadata, and use that to map the entry to the correct locale** You can use the locale value to map the collection to a different route if desired*/export const localizedCollections = {blog: {en: "blog",fr: "blog",},// Add more collections/locales as needed} as const;- This is accomplished in the new
Add wildcard support in the
routeTranslations
object, allowing you to map multiple routes at once.- For example, you could route all English category routes
/categories/*
to the base French route of/categories
src/config/translationData.json.ts /*** * Route translations are used to translate route names for the language switcher component* This can be useful for SEO reasons. The key does not matter, it just needs to match between languages** These routes must be everything after the base domain. So if this is "atlas.com/blog", the route would be "blog"* Or if this is "atlas.com/legal/privacy", the route would be "legal/privacy"** This also supports wildcards. For example, "categories/*" would match "categories/1" or "categories/2" etc for that language.** Note: This works in conjunction with the localizedCollections object*/export const routeTranslations = {en: {overviewKey: "overview",categoryKey: "categories",categoryKey2: "categories/*",categoryKey3: "categories",},fr: {overviewKey: "apercu",categoryKey: "categories",categoryKey2: "categories",categoryKey3: "categories/*",},} as const;- For example, you could route all English category routes
Adjust existing i18n config script to account for additional features
Lock package version to limit potential issues with new package updates
Improve
.prettierignore
fileUpgrade to Astro 5.7.5
- Removed experimental SVG setup in Astro config file as a result (it is now a stable feature)
Update other dependencies
1.0.2 - 2025-04-05
- Remove pricing table logging
- Fix nav script duplication bug when navigating to the 404 page with View Transitions (ClientRouter) enabled
- Upgrade to Astro 5.6.1
- Update other dependencies
1.0.1 - 2025-03-30
- i18n script fixes
1.0.0 - 2025-03-29
- Initial release