Skip to content

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Aug 24, 2025

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@inlang/[email protected]

Major Changes

  • 7791be7: Upgraded the inlang SDK to Lix v0.5 🎉

    Highlights

    Writing directly to Lix state

    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:

    • history and branching,
    • writer-key aware workflows,
    • change proposals and subscriptions, and
    • a single source of truth for downstream tools.

    Per-file filesystem sync

    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 where editing one key in en.json would re-export every other locale file, destroying manual formatting or reintroducing stale content.

    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.

@inlang/[email protected]

Minor Changes

  • ff07482: Require the INLANG_GOOGLE_TRANSLATE_API_KEY environment variable for machine translations.

    We previously subsidized machine translation costs. As projects become larger, our bill is no longer sustainable.

    To ensure that machine translations remain available, we are switching to a Bring Your Own Key (BYOK) model.

    Before

    npx @inlang/cli machine translate --project ./project.inlang

    After

    export INLANG_GOOGLE_TRANSLATE_API_KEY="your-google-api-key"
    npx @inlang/cli machine translate --project ./project.inlang
  • 7791be7: Upgraded the inlang SDK to Lix v0.5 🎉

    Highlights

    Writing directly to Lix state

    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:

    • history and branching,
    • writer-key aware workflows,
    • change proposals and subscriptions, and
    • a single source of truth for downstream tools.

    Per-file filesystem sync

    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 where editing one key in en.json would re-export every other locale file, destroying manual formatting or reintroducing stale content.

    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.

Patch Changes

@inlang/[email protected]

Minor Changes

  • 7791be7: Upgraded the inlang SDK to Lix v0.5 🎉

    Highlights

    Writing directly to Lix state

    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:

    • history and branching,
    • writer-key aware workflows,
    • change proposals and subscriptions, and
    • a single source of truth for downstream tools.

    Per-file filesystem sync

    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 where editing one key in en.json would re-export every other locale file, destroying manual formatting or reintroducing stale content.

    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.

Patch Changes

@lix-js/[email protected]

Minor Changes

  • b785bbd: Switch HTML diff parsing from the browser-only DOMParser to server-friendly parse5 so the library can run in Node, workers, and other isomorphic environments without DOM shims.

@inlang/[email protected]

Patch Changes

@inlang/[email protected]

Patch Changes

@inlang/[email protected]

Patch Changes

@inlang/[email protected]

Patch Changes

@inlang/[email protected]

Patch Changes

[email protected]

Minor Changes

  • 9a65cb4: Add centralized Sherlock logging so activation and project loading diagnostics are visible in the VS Code output tab, refine the direct message watcher to stop self-saving loops, make the editor webview always load bundled assets, and debounce editor writes while still saving projects to disk.

Patch Changes

@inlang/[email protected]

Patch Changes

[email protected]

Patch Changes

@opral/[email protected]

Patch Changes

@lix-js/[email protected]

Patch Changes

@lix-js/[email protected]

Patch Changes

[email protected]

Patch Changes

@github-actions github-actions bot force-pushed the changeset-release/main branch from 0afe0db to 7d95a63 Compare August 25, 2025 01:24
@github-actions github-actions bot force-pushed the changeset-release/main branch 9 times, most recently from 7a1541e to 015f541 Compare September 7, 2025 00:25
@github-actions github-actions bot force-pushed the changeset-release/main branch 14 times, most recently from 67859ca to 921e7fa Compare September 23, 2025 23:26
@github-actions github-actions bot force-pushed the changeset-release/main branch 3 times, most recently from 06a43b8 to 0646ef2 Compare September 27, 2025 00:22
@github-actions github-actions bot force-pushed the changeset-release/main branch 2 times, most recently from 00d2d00 to adf430a Compare September 30, 2025 17:49
@github-actions github-actions bot force-pushed the changeset-release/main branch 8 times, most recently from b3e44c8 to 01c69d6 Compare October 6, 2025 19:52
@github-actions github-actions bot force-pushed the changeset-release/main branch from 01c69d6 to 1646cfc Compare October 14, 2025 21:48
@github-actions github-actions bot force-pushed the changeset-release/main branch 2 times, most recently from 638345a to 724828d Compare October 22, 2025 18:20
@github-actions github-actions bot force-pushed the changeset-release/main branch from 865e0db to 8c4aebf Compare October 22, 2025 18:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant