🌐 Aegis Localizer

🎯 What Aegis Localizer Is

Every application starts with strings written straight into the code. Making that application speak a second language usually means a developer reading every file by hand, deciding which strings a user actually sees, moving them into resource files, and then rewriting the call sites. It is slow, mechanical work that nobody wants to do twice.

Aegis Localizer does that pass for you. It parses your source, separates user-facing text from machine strings such as URLs, SQL and identifiers, asks Claude to classify the ambiguous cases, translates what remains into the languages you asked for, writes the resource files in the format your stack expects, and, when you tell it to, rewrites the source so the code reads from those resources.

It is built to be run repeatedly. Verdicts and translations are cached, so a second run costs nothing where nothing changed; a reworded English string goes stale and is redone, while a new language reuses the classification work already paid for.

🏢 Who It Is For

• Product teams going multilingual: an existing single-language application that now needs to ship in five, ten or twenty markets.
• .NET teams: C# is parsed with Roslyn, so verbatim, raw and interpolated strings are decoded correctly with exact source spans.
• Web, mobile and cross-platform teams: React, Vue, Svelte, Android, iOS and Flutter projects are handled with the same pipeline.
• Platform and build engineers: scan-only mode with JSON output turns the tool into a CI gate that catches new hardcoded strings at review time.
• Agencies and consultancies: localize a client codebase in an afternoon instead of quoting a multi-week manual project.

⚙️ How It Works

Six stages, each one designed to spend as little of your API budget as possible and to refuse rather than guess when it is not certain.

🧩 Supported Stacks

Five platforms, each with its own reader, resource format and rewrite style. Automatic platform detection inspects the project tree, and a working sample project ships for every stack.

Point the tool at a repository with automatic detection and it works out which of these applies before it reads a single string.

🛡️ Safety and Correctness

A missed string costs you a minute. A broken build costs you an afternoon. The tool is deliberately built to report rather than guess whenever a rewrite is not provably correct.

• Byte-for-byte backups: every file the tool rewrites is copied first, so any run can be undone completely.
• Span verification: a file edited between the scan and the rewrite is skipped, not patched at stale offsets.
• Placeholder validation: a translation that loses or invents a placeholder such as {0}, %s or {{count}} is rejected before it reaches a resource file.
• Absent beats wrong: a failed translation leaves the key missing so the application falls back to English, and the next run retries it.
• Merge, not overwrite: resource stores merge into existing bundles, so translations a human corrected by hand stay corrected.
• Schema-validated model output: classification goes through a forced tool call, so the pipeline consumes structured data rather than parsing prose.

🔧 Problems It Solves

• The manual extraction pass: no more reading every file to decide which strings a user actually sees.
• Cost of AI translation: an offline filter and a cached, language-independent classification pass mean the API is only asked about strings that might matter.
• Adding the tenth language: classification is paid for once; each new language only pays for the translation itself.
• Drift after a copy change: translations are tracked against the English they came from, so reworded text is detected and redone.
• Regression on new code: scan-only mode with JSON output can fail a build when someone adds a fresh hardcoded string.
• Broken formatting in translations: placeholder validation catches the class of bug that only shows up at runtime in a language nobody on the team reads.

🚀 Ways to Run It

🚧 What It Does Not Do

Being explicit about the boundaries is part of the design. The tool is meant to remove the mechanical work, not to take responsibility for your release.

• It does not replace a human reviewer on customer-facing copy, brand voice or legal text.
• It does not restructure your application's localization architecture; it fits the resource conventions your stack already uses.
• It does not touch strings it cannot rewrite safely; those are reported for you to handle.
• It does not run your build or your tests, so review the diff and run them as usual.
• It does not do layout work: text length changes between languages are still yours to design for.

🛠️ Technology Stack