Caching: The i18n.lock File

Lingo.dev uses a lockfile (i18n.lock) to optimize translation updates. Here's why it matters and how it works.

What's the i18n.lock file?

It's file that stores checksums of your source content. Think of it as Lingo.dev's memory of what it's seen before.

Why use a lockfile?

1. Speed: Lingo.dev only translates what's changed;
2. Consistency: Prevents unnecessary retranslations of unchanged content;
3. Cost-efficiency: You're not billed for translating the same thing twice.

How it works

1. Lingo.dev calculates checksums for your source content;

2. It compares these with the stored checksums in i18n.lock;

3. Only content with new or changed checksums gets translated.

Key Renames and Caching

Lingo.dev's caching system is smart enough to detect when you've renamed a translation key without changing its content:

1. When a key is renamed but its content stays the same, the cache recognizes this as a rename operation
2. Translations are preserved and applied to the new key name
3. No retranslation occurs, saving time and costs

This works automatically, but if both the key name AND content change, Lingo.dev will treat it as new content requiring translation.

For more details, see our Key Renames documentation.

Pro tips

1. Always commit i18n.lock. It's crucial for tracking changes.

2. Use --force to ignore the lockfile and retranslate everything:

   npx lingo.dev@latest i18n --force

   Useful after changing AI context settings.

3. The --frozen flag is great for CI/CD to catch missing translations:

   npx lingo.dev@latest i18n --frozen

Remember, Lingo.dev's goal is to make localization a set-it-and-forget-it process. The lockfile is a key part of that, ensuring you're always efficient with your translations.