|
1 | 1 | # @inlang/paraglide-js |
2 | 2 |
|
| 3 | +## 2.5.0 |
| 4 | + |
| 5 | +### Minor Changes |
| 6 | + |
| 7 | +- 7791be7: Upgraded the [inlang SDK](https://github.com/opral/inlang-sdk) to [Lix](https://lix.dev/) v0.5 🎉 |
| 8 | + |
| 9 | + ## Highlights |
| 10 | + |
| 11 | + ### Writing directly to Lix state |
| 12 | + |
| 13 | + State is now written straight into Lix instead of the SDK’s private in-memory SQLite snapshot. Every bundle, message, and variant change becomes a first-class Lix commit, unlocking: |
| 14 | + |
| 15 | + - history and branching, |
| 16 | + - writer-key aware workflows, |
| 17 | + - change proposals and subscriptions, and |
| 18 | + - a single source of truth for downstream tools. |
| 19 | + |
| 20 | + ### Per-file filesystem sync |
| 21 | + |
| 22 | + Any inlang-based tooling that opens a project from disk (IDE extensions, CLIs, custom apps) used to patch the entire locale tree whenever a single message changed. That behaviour is at the heart of [opral/inlang-sherlock#173](https://github.com/opral/inlang-sherlock/issues/173) where editing one key in `en.json` would re-export every other locale file, destroying manual formatting or reintroducing stale content. |
| 23 | + |
| 24 | + Thanks to Lix v0.5’s observable state and writer-key APIs we can now react to per-commit metadata and suppress our own writes. When `happy_elephant` in `en.json` is updated, the SDK marks only `en.json` as dirty, leaving `de.json` and friends untouched. Drift is still possible if another tool rewrites `en.json`, yet the blast radius falls from “the whole project just changed” to “only the file you touched,” making reviews and merges manageable across all inlang integrations. |
| 25 | + |
| 26 | +### Patch Changes |
| 27 | + |
| 28 | +- Updated dependencies [7791be7] |
| 29 | + - @inlang/sdk@3.0.0 |
| 30 | + |
3 | 31 | ## 2.4.0 |
4 | 32 |
|
5 | 33 | ### Minor Changes |
|
52 | 80 | This change introduces a new `extractLocaleFromRequestAsync` function that supports asynchronous custom server strategies, enabling use cases like fetching user locale preferences from databases. |
53 | 81 |
|
54 | 82 | ## What's Changed |
| 83 | + |
55 | 84 | - **New Function**: Added `extractLocaleFromRequestAsync` that supports async custom server strategies |
56 | 85 | - **Middleware Update**: Server middleware now uses the async version to support async custom strategies |
57 | 86 | - **Breaking Change**: The synchronous `extractLocaleFromRequest` no longer supports custom server strategies |
|
120 | 149 | ``` |
121 | 150 |
|
122 | 151 | **Migration**: |
| 152 | + |
123 | 153 | - If you want the previous behavior (subdomain sharing), explicitly set `cookieDomain` in your configuration: |
124 | 154 |
|
125 | 155 | ```diff |
|
137 | 167 | - 4255bd5: Provide functions for getting the preferred language on server and client. |
138 | 168 |
|
139 | 169 | This defines two new functions for getting the preferred language: |
| 170 | + |
140 | 171 | - `extractLocaleFromHeader`: Extracts the locale from the accept-language header on the server. |
141 | 172 | - `extractLocaleFromNavigator`: Extracts the locale from the navigator.languages array on the client. |
142 | 173 |
|
|
148 | 179 | This introduces a new way to define custom locale resolution strategies alongside built-in strategies. Custom strategies provide a cleaner, more composable approach compared to overwriting `getLocale()` and `setLocale()` functions directly. |
149 | 180 |
|
150 | 181 | **New APIs:** |
| 182 | + |
151 | 183 | - `defineCustomClientStrategy()`: Define custom strategies for client-side locale resolution |
152 | 184 | - `defineCustomServerStrategy()`: Define custom strategies for server-side locale resolution |
153 | 185 |
|
154 | 186 | **Key features:** |
| 187 | + |
155 | 188 | - Custom strategies must follow the pattern `custom-<name>` where `<name>` contains only alphanumeric characters |
156 | 189 | - Can be combined with built-in strategies in the strategy array |
157 | 190 | - Respect strategy order for fallback handling |
|
274 | 307 | - 698b9a9: add `cookieMaxAge` option to compiler and runtime |
275 | 308 |
|
276 | 309 | Closes https://github.com/opral/inlang-paraglide-js/issues/483 |
| 310 | +
|
277 | 311 | - Introduced `cookieMaxAge` option to `CompilerOptions`, allowing configuration of cookie expiration time. |
278 | 312 | - Adjusted tests to verify `max-age` in cookies. |
279 | 313 |
|
@@ -992,6 +1026,7 @@ await compile({ |
992 | 1026 | - 14d80b3: Removed the "Which tech-stack are you using?" prompt from the `init` command as it was not providing any real value. All it did was link you to the appropriate documentation. |
993 | 1027 |
|
994 | 1028 | From now on we rely on the docuemntation site to guide people to the correct documenation for their framework. |
| 1029 | +
|
995 | 1030 | - SvelteKit: https://inlang.com/m/dxnzrydw/paraglide-sveltekit-i18n |
996 | 1031 | - NextJs: https://inlang.com/m/osslbuzt/paraglide-next-i18n |
997 | 1032 | - Astro: https://inlang.com/m/iljlwzfs/paraglide-astro-i18n |
|
0 commit comments