Languine - AI CLI That Translates Your App in Seconds

TL;DR

TL;DR: Languine is an open-source AI CLI that auto-translates your app’s strings across 16+ file formats (JSON, MDX, iOS, Android, Flutter, and more) via a CI/CD pipeline — no manual translation work required.

Source and Accuracy Notes

This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: languine.ai — verified
• Source repository: Not publicly linked in docs; the site claims full open source on GitHub but the actual repo URL could not be extracted from the HTML
• License: Open source (self-described on website; specific license not stated in extracted docs)
• HN launch thread: news.ycombinator.com/item?id=42540077 — Show HN from November 2025
• Source last checked: 2026-07-29 (live docs at languine.ai)

What Is Languine?

Languine is an AI-powered localization platform built around a CLI tool. The developer writes their source strings once, runs npx languine@latest translate, and Languine generates translated files for all configured target languages. Translations are submitted as pull requests, which you review before merging.

The tool started as an internal utility at Midday before being open-sourced. The founder demoed it on Show HN in late 2025.

Key capability claims (from official docs):

• Supports 16+ file formats: JSON, YAML, Properties, Android XML, iOS Strings/XCStrings, Markdown, MDX, HTML, JavaScript, TypeScript, Gettext PO, XLIFF, CSV, Flutter ARB, PHP
• Translation engine with context awareness and brand voice consistency
• Terminology management to preserve key terms across translations
• GitHub Action for fully automated CI/CD translation updates
• Translation overrides: edit specific keys via dashboard without re-running the full pipeline
• Translation state tracking via a languine.lock file

Setup Workflow

Step 1: Install

npx languine@latest init

This scaffolds a languine.json configuration file in your project.

Step 2: Configure

Edit languine.json to define your source language, target languages, and which files to translate:

{
  "locale": {
    "source": "en",
    "targets": ["es", "fr", "de"]
  },
  "files": {
    "json": {
      "include": ["locales/[locale].json"]
    }
  }
}

The [locale] placeholder is automatically replaced with the target language code (e.g., locales/es.json).

Step 3: Authenticate

npx languine@latest auth

Step 4: Translate

npx languine@latest translate

Languine analyzes the modified source content, generates translations using its AI engine, and submits a pull request with the updated files.

Step 5: Add or Remove Languages

npx languine@latest locale add pt,ja
npx languine@latest locale remove pt,ja

Step 6: Pull Translation Overrides

If you’ve edited specific translations via the Languine dashboard:

npx languine@latest overrides pull

CI/CD Integration

Languine provides a GitHub Action (available on Pro plans) that runs on every push. When source content changes, the action automatically triggers a new translation pass and opens a PR with the updated target files. This keeps translations in sync with development without manual intervention.

Supported File Formats

From the official docs, Languine handles these formats natively:

| Format | Notes | |---|---| | JSON | Most common i18n format | | YAML | Alternative to JSON | | Properties | Java/Android | | Android XML | Android string resources | | iOS Strings | Traditional .strings files | | iOS XCStrings | Modern Xcode localization format | | Markdown / MDX | Documentation and content | | HTML | Web content | | JavaScript / TypeScript | Inline i18n | | Gettext PO | GNU gettext format | | XLIFF | Industry standard interchange | | CSV | Spreadsheet-based | | Flutter ARB | Flutter app resources | | PHP | PHP translation files |

Pricing

From languine.ai/pricing:

• Free: Up to 500 translated keys, unlimited projects, fine-tuning options, translation overrides, analytics, context memory, community support
• Pro: Starting from 3,000 keys, GitHub Action integration, priority support and translation queues, starting from 4 languages. Special 30% discount for open source projects

A “translated key” is counted as one source key translated into one target language (e.g., 20 source keys into 5 languages = 100 translated keys).

Practical Evaluation Checklist

• [x] CLI-first workflow — no web UI required for core operations
• [x] GitHub Action available for automated CI/CD
• [x] Supports 16+ file formats covering web, mobile, and desktop
• [x] Translation override system via dashboard
• [x] languine.lock tracks translation state to avoid re-translating unchanged keys
• [x] Open source (self-described; repo URL not found in docs)
• [x] Free tier available for small projects

Security Notes

• Project ID is stored via the LANGUINE_PROJECT_ID environment variable, not hardcoded in config files
• The languine.lock file should be committed to version control alongside languine.json to track translation state across deployments
• Credentials are managed via languine auth (OAuth/GitHub sign-in on the platform side)

FAQ

Q: Does Languine work offline? A: The core translation engine requires an internet connection to call Languine’s AI API. The CLI itself can be installed and run offline, but translations will not be generated without API access.

Q: Can I use my own translation API key? A: Languine uses its own translation engine by default. The docs do not mention support for bring-your-own-provider at this time.

Q: What happens to existing translations when I add new source strings? A: Languine’s lock file (languine.lock) tracks which content has already been translated. New or changed keys are picked up on the next translate run; existing translations are preserved.

Q: Is there a way to preview translations before applying them? A: Yes. Translations are submitted as pull requests, giving you the opportunity to review and edit before merging into your codebase.

Conclusion

Languine targets developer workflows where translation is a recurring friction point — every feature release that adds UI strings should not require a manual handoff to translators. The CLI-first design means it slots into existing CI/CD pipelines without a platform lock-in requirement for small projects. The free tier is generous enough to evaluate on a real project before committing to a paid plan.