DEV Community: Nikolaos Protopapas

Building Terminal UIs in .NET: How SharpConsoleUI Complements Terminal.Gui

Nikolaos Protopapas — Fri, 06 Mar 2026 23:02:31 +0000

The .NET terminal UI space has a clear champion: Terminal.Gui, created by Miguel de Icaza — the same mind behind Mono, Xamarin, and GNOME. With 10.7K stars, 1.6M NuGet downloads, and 199 contributors, it's the most mature and widely-used TUI framework in the .NET ecosystem. It set the standard for what's possible in a terminal.

SharpConsoleUI is a much younger, much smaller project that takes a different architectural approach. It doesn't aim to replace Terminal.Gui — it fills a niche that Terminal.Gui wasn't designed for. This post explains the differences so you can pick the right tool for your use case.

Different Problems, Different Architectures

Terminal.Gui follows the classic single-threaded event loop model — the same proven pattern as WinForms. One main loop handles input, layout, and painting. Background work is marshaled back via Application.Invoke(). This is well-understood, safe, and works perfectly for form-based applications, dialogs, and configuration UIs.

SharpConsoleUI uses a multi-threaded compositor model. Each window can have its own async thread updating independently, and the rendering engine composites everything together using a double-buffered cell pipeline with dirty-region tracking. This is closer to how a desktop compositor works — each window paints to its own buffer, and the screen-level buffer diff-scans and outputs only changed cells.

// SharpConsoleUI: Each window updates on its own thread
var monitor = new WindowBuilder(windowSystem)
    .WithTitle("System Monitor [1s refresh]")
    .WithAsyncWindowThread(async (window, ct) =>
    {
        while (!ct.IsCancellationRequested)
        {
            UpdateMetrics(window); // Doesn't block other windows
            await Task.Delay(1000, ct);
        }
    })
    .Build();

Neither approach is objectively better — they solve different problems. Terminal.Gui's model is simpler and safer. SharpConsoleUI's model enables scenarios that are awkward in a single-threaded loop.

Rendering Pipeline

Terminal.Gui v2 has a modern rendering system with TrueColor support, automatic 16-color fallback, and a LineCanvas that handles line intersection merging. Views draw within their bounds, and the framework manages repainting.

SharpConsoleUI implements a DOM-based Measure → Arrange → Paint pipeline (inspired by WPF/Avalonia) with three additional features:

Occlusion culling — content hidden behind other windows is never rendered
Adaptive rendering — each line is analyzed and rendered as cells or full lines based on coverage heuristics
Compositor hooks — PreBufferPaint/PostBufferPaint let you manipulate the rendered buffer for effects like blur, fade, or animated backgrounds

All rendering flows through typed Cell structs. ANSI is generated once at the terminal output boundary. On Unix, SharpConsoleUI bypasses .NET's Console infrastructure entirely using raw libc I/O — a technique inspired by Terminal.Gui v2's own approach to solving the terminal echo leak bug.

Controls Comparison

Both frameworks provide rich control libraries:

Category	Terminal.Gui v2	SharpConsoleUI
Input	Button, CheckBox, RadioGroup, TextField, TextView	ButtonControl, CheckboxControl, PromptControl, MultilineEditControl
Data	ListView, TableView (sorting/filtering), TreeView	ListControl, TableControl, TreeControl
Menus	MenuBar, PopoverMenu	MenuControl (horizontal/vertical, nested submenus)
Tabs	TabView	TabControl
Layout	FrameView, TileView, ScrollView	ColumnContainer, HorizontalGridControl, ScrollablePanelControl, SplitterControl
Dialogs	Dialog, FileDialog, Wizard	Built-in file picker, folder browser, notification system

Terminal.Gui has more specialized controls: ColorPicker, DatePicker, NumericUpDown, Wizard, CharMap, GraphView, FlagSelector. Its control library is broader — that's the advantage of 8 years and 199 contributors.

SharpConsoleUI has unique controls that don't exist in Terminal.Gui:

CanvasControl — Free-form drawing surface with 30+ primitives (circles, polygons, gradients, arcs), supporting retained and immediate rendering modes
TerminalControl — Embedded PTY-based terminal emulator (run bash, vim, htop inside your TUI app)
SparklineControl — Real-time sparkline graphs (block, braille, bidirectional modes)
BarGraphControl — Horizontal bar graphs with gradient color thresholds

Spectre.Console

Terminal.Gui has its own rendering and theming system — it's self-contained.

SharpConsoleUI is built on top of Spectre.Console. Any [bold red]markup[/] works anywhere, and any Spectre IRenderable (Tables, Trees, BarCharts, Panels) can be used as a control via SpectreRenderableControl. If you're already in the Spectre.Console ecosystem, SharpConsoleUI extends it rather than replacing it.

Layout

Terminal.Gui uses Pos and Dim types for powerful relative positioning — Pos.Center(), Pos.Percent(50), Dim.Fill(), Dim.Auto(). This is more expressive for complex layouts.

SharpConsoleUI uses a simpler stack/grid/fill model with alignment properties. It covers common layouts well but doesn't match Terminal.Gui's positioning flexibility.

Terminal.Gui wins on layout expressiveness.

The Numbers

	Terminal.Gui	SharpConsoleUI
Stars	10,700	36
NuGet Downloads	1.6M	6.4K
Contributors	199	1
First Release	2017	2025
Status	v2 beta	v2.4 stable
.NET	.NET Standard 2.0+	.NET 9.0
License	MIT	MIT

These numbers tell the story. Terminal.Gui is a mature, community-driven project with years of battle-testing. SharpConsoleUI is a solo project that's been in active development for about a year. If community size and ecosystem maturity are your primary concerns, Terminal.Gui is the obvious choice.

When to Reach for SharpConsoleUI

SharpConsoleUI makes sense when you need something Terminal.Gui wasn't designed around:

Multi-window dashboards where each panel updates independently at different rates — the per-window async thread model makes this natural
Real-time animations or high-frequency updates — the compositor architecture achieves 25+ fps over SSH
Compositor effects — buffer-level post-processing for transitions, blur, custom rendering
Embedded terminal emulators — the PTY-based TerminalControl runs real shell processes
Free-form drawing — CanvasControl for games, visualizations, or interactive graphics
Spectre.Console extension — adding windowing to an existing Spectre.Console project

When to Reach for Terminal.Gui

For most .NET terminal applications, Terminal.Gui is the right choice:

Largest community and most third-party resources
Broadest .NET compatibility (.NET Standard 2.0)
More specialized controls (ColorPicker, DatePicker, Wizard)
Proven in production across the ecosystem
Familiar WinForms-like programming model
Better layout system for complex relative positioning
Active development with 199 contributors

Acknowledgments

Terminal.Gui paved the way for serious TUI development in .NET. SharpConsoleUI's own Unix input handling was directly inspired by Terminal.Gui v2's approach to bypassing .NET's Console APIs. Building on the shoulders of the work done by Miguel de Icaza and the Terminal.Gui community is what open source is about.

Real-World Applications

Terminal.Gui powers numerous production tools across the .NET ecosystem.

SharpConsoleUI powers:

ServerHub — Linux server monitoring dashboard with 14 real-time widgets
LazyNuGet — Terminal-based NuGet package manager
LazyDotIDE — Console-based .NET IDE with LSP IntelliSense

Links:

SharpConsoleUI: GitHub | NuGet | Docs | Video Demo
Terminal.Gui: GitHub | NuGet | Docs

lazygit-style TUI for NuGet

Nikolaos Protopapas — Sat, 21 Feb 2026 17:22:09 +0000

If you've ever used lazygit, you know the feeling. Git stops being a chore and becomes almost enjoyable. You can see everything at once, navigate with the keyboard, and do in seconds what used to take several commands.

I wanted that for NuGet.

dotnet list package --outdated gives you a wall of text. Updating means running a separate command for each package. Checking for vulnerabilities is another command. Searching NuGet.org is yet another. And if you're working across a solution with 10+ projects, you're context-switching constantly.

So I built LazyNuGet.

What it does

You point it at a folder and it scans for all .csproj files. Every project, every package, every version — all in one place. In the background it quietly checks NuGet.org for updates and vulnerability data. When it's done, the outdated packages light up yellow. Vulnerable ones show a red badge. You don't have to ask.

From there you can:

Update a single package or everything at once (Ctrl+U)
Search NuGet.org without leaving the terminal (Ctrl+S) — browse results, read descriptions, pick a version, install to one or multiple projects
View the dependency tree for any project or package (Ctrl+D)
Migrate deprecated packages to their recommended replacements in one step
Browse version history, release notes, security advisories, and download stats in tabbed panels (F1–F5)
Track operation history and undo or retry recent changes (Ctrl+H)
Work with private feeds — authenticated NuGet sources with stored credentials

It's fully usable with both keyboard and mouse.

Selecting a package gives you a tabbed view — overview, dependencies, version history, release notes, and security advisories. All fetched live from NuGet.org.

The search modal lets you browse NuGet.org, read package descriptions, and install to one or multiple projects — without leaving the terminal.

Getting started

If you have .NET 10 installed:

dotnet tool install --global LazyNuGet
lazynuget

Or grab the self-contained binary (no .NET required):

curl -fsSL https://raw.githubusercontent.com/nickprotop/lazynuget/main/install.sh | bash

Then just run it:

lazynuget /path/to/your/solution
# or just cd there and run lazynuget

The stack

Built with .NET 10, Spectre.Console, and SharpConsoleUI — a TUI layout library I also wrote that handles responsive panels, window management, and mouse support in the terminal.

It's early

If you try it, I'd genuinely love to hear what breaks or what's missing. Issues and stars both appreciated.

GitHub: github.com/nickprotop/lazynuget

How I Translated 277 Strings in 5 Minutes (Real-World Case Study)

Nikolaos Protopapas — Sun, 04 Jan 2026 18:44:15 +0000

The Challenge

ShareX is an amazing open-source screen capture tool with 35K+ GitHub stars. It supports 24 languages with 170 translatable strings.

I wanted to:

Add Greek as a new language
Complete Spanish translations
Find any unused localization keys

And I wanted to do it for free - no paid translation APIs.

The Tool: LRM

LRM (Localization Resource Manager) is an open-source CLI tool I built for managing localization files. It supports:

.resx (ShareX uses this), JSON, i18next, Android, iOS, PO, XLIFF
Free translation providers: MyMemory, Lingva, LibreTranslate
Local LLMs: Ollama (Llama, Mistral, etc.)
Paid providers: DeepL, Google, Azure, OpenAI, Claude (if you need them)

Step 1: Check Current Status

cd ~/ShareX/ShareX/Properties
lrm stats

┌─────────────────────────────────────────────────────────────────┐
│                     Localization Statistics                     │
├──────────┬──────┬────────────┬───────┬─────────┬─────────┬──────┤
│ Language │ Keys │ Translated │ Empty │ Missing │ Coverage│ Size │
├──────────┼──────┼────────────┼───────┼─────────┼─────────┼──────┤
│ default  │  170 │        170 │     0 │       0 │  100.0% │ 48KB │
│ de       │  163 │        163 │     0 │       7 │   95.9% │ 47KB │
│ es       │   63 │         63 │     0 │     107 │   37.1% │ 20KB │
│ fr       │  170 │        170 │     0 │       0 │  100.0% │ 50KB │
│ ...      │      │            │       │         │         │      │
└──────────┴──────┴────────────┴───────┴─────────┴─────────┴──────┘

Spanish at 37%? Let's fix that.

Step 2: Add Greek (New Language)

lrm add-language el

✓ Created: Resources.el.resx
  Keys: 170 (copied from default)
  All values empty - ready for translation

Step 3: Translate with Free Providers

Option A: MyMemory (Free, No API Key)

# Translate Greek (all strings)
lrm translate "*" --provider mymemory --from en --to el

# Complete Spanish (only missing)
lrm translate "*" --provider mymemory --from en --to es --only-missing

Option B: Lingva (Free Google Translate Proxy)

lrm translate "*" --provider lingva --from en --to el

Option C: Local Ollama (100% Offline)

If you have Ollama running locally:

# Use Llama 3.2 or any model you have
lrm translate "*" --provider ollama --from en --to el

Configure the model in lrm.json:

{
  "Translation": {
    "AIProviders": {
      "Ollama": {
        "Model": "llama3.2",
        "ApiUrl": "http://localhost:11434"
      }
    }
  }
}

Step 4: Validate

lrm validate

✓ Validation passed
  Files: 25
  Issues: 0
  Placeholder mismatches: 0

LRM automatically checks that {0}, {1} placeholders are preserved.

Step 5: Find Unused Keys

lrm scan --show-unused

Code Scan Results
─────────────────
Source files scanned: 847
Localization keys: 170

Unused Keys (5):
  • HotkeyType_DisableHotkeys
  • QuickTaskMenuEditorForm_Separator
  • TaskSettings_CaptureAutoHideTaskbar
  • ...

Found 5 keys that exist in .resx but aren't used in code!

Results

Language	Before	After	Strings
Greek	0%	100%	170 new
Spanish	37%	100%	107 added

Total: 277 strings in ~5 minutes

Bonus: Team Collaboration with LRM Cloud

For team projects, sync to LRM Cloud (free tier available):

lrm cloud push

Features:

Web-based translation editor
Translation Memory & Glossary
GitHub integration
Role-based team access

Full Case Study

See the complete walkthrough with all CLI output:

ShareX Case Study on GitHub

Get Started

# Download LRM
curl -L https://github.com/nickprotop/LocalizationManager/releases/latest/download/lrm-linux-x64.tar.gz | tar xz

# Or on Windows
# Download from GitHub Releases

# Check your project
cd ./YourProject/Resources
lrm stats

Links:

Have questions? Drop a comment or open a GitHub Discussion!

The $0 Localization Stack for Solo .NET Developers

Nikolaos Protopapas — Mon, 29 Dec 2025 22:58:02 +0000

How I Translated My .NET App to 5 Languages for $0 (As a Solo Dev)

I'm a solo developer with a medical practice app built in .NET. It started as an English-only app, then users asked for Greek. Then more languages. That's when I discovered localization platforms cost $100-500/month.

For a side project? No way.

So I built my own solution. Here's how you can translate your .NET app for free too.

The Problem

I had 400+ strings in my app. I needed translations for at least Greek and English, ideally more. My options:

Option	Cost	Time
Lokalise	$120/mo	Fast
Phrase	$25/mo	Fast
Manual Google Translate	$0	Hours of copy-paste hell
Hire translator	$100+	Days

None of these worked for a solo dev with a side project.

The Solution: Local LLM Translation

What if you could run a translation model on your own machine? No API costs, no rate limits, no data leaving your computer.

That's exactly what I built into LRM (Localization Resource Manager).

Setup (5 minutes)

1. Install Ollama (the local LLM runtime):

# Linux
curl -fsSL https://ollama.ai/install.sh | sh

# Windows/Mac - download from https://ollama.ai

2. Pull a model:

ollama pull llama3.2
# Or for better quality: ollama pull llama3.1:8b

3. Install LRM:

# Linux (one-liner)
curl -sSL https://raw.githubusercontent.com/nickprotop/LocalizationManager/main/install-lrm.sh | bash

# Or via APT (Ubuntu/Debian)
sudo add-apt-repository ppa:nickprotop/lrm-tool
sudo apt install lrm-standalone

# Windows/macOS - download from GitHub releases
# https://github.com/nickprotop/LocalizationManager/releases

That's it. No API keys, no accounts, no credit cards.

Translate Everything

# Navigate to your project
cd MyApp/Resources

# Translate all missing keys to Spanish, French, German
lrm translate --only-missing --provider ollama --target-languages es,fr,de

That's it. LRM finds all your resource files, identifies missing translations, and fills them in using the local LLM.

400+ keys × 3 languages = 1,200+ translations. Zero dollars. Under 10 minutes.

No GPU? No Problem.

Don't have a beefy GPU? Use the free online providers - still $0:

MyMemory (No signup required)

lrm translate --only-missing --provider mymemory --target-languages es,fr,de

5,000 characters/day free. Enough for most projects.

Lingva (Google Translate quality, free)

lrm translate --only-missing --provider lingva --target-languages es,fr,de

Uses open-source proxy to Google Translate. No API key needed.

Real Example

Here's my actual workflow for adding Italian to my app:

# Add a new language file
lrm add-language --culture it

# Check what's missing
lrm stats

                         Localization Statistics
┌───────────────┬────────────┬───────────┬───────┬──────────┬───────────┐
│ Language      │ Total Keys │ Completed │ Empty │ Coverage │ File Size │
├───────────────┼────────────┼───────────┼───────┼──────────┼───────────┤
│ Default       │ 12         │ 12        │ 0     │ 100.0%   │ 1.8 KB    │
│ Deutsch (de)  │ 12         │ 5         │ 7     │ 41.7%    │ 1.6 KB    │
│ français (fr) │ 12         │ 7         │ 5     │ 58.3%    │ 1.7 KB    │
│ italiano (it) │ 12         │ 0         │ 12    │ 0.0%     │ 1.6 KB    │
└───────────────┴────────────┴───────────┴───────┴──────────┴───────────┘

Italian at 0%! Let's fix that:

# Translate Italian with one command
lrm translate --only-missing --provider ollama --target-languages it

╭────────────────────┬──────────┬─────────────────────────────────────┬────────╮
│ Key                │ Language │ Translation                         │ Status │
├────────────────────┼──────────┼─────────────────────────────────────┼────────┤
│ AppTitle           │ it       │ Responsabile dello studio medico    │ ✓      │
│ WelcomeMessage     │ it       │ Eccoci di nuovo, {0}!               │ ✓      │
│ LoginButton        │ it       │ Accedi                              │ ✓      │
│ LogoutButton       │ it       │ Disconnettere                       │ ✓      │
│ SaveButton         │ it       │ Salva                               │ ✓      │
│ CancelButton       │ it       │ Cancella                            │ ✓      │
│ DeleteConfirmation │ it       │ Sei sicuro di voler eliminare...    │ ✓      │
│ ErrorOccurred      │ it       │ Si è verificato un errore...        │ ✓      │
│ PatientName        │ it       │ Nome del paziente                   │ ✓      │
│ AppointmentDate    │ it       │ Data prenotazione                   │ ✓      │
│ NoResultsFound     │ it       │ Nessun risultato trovato            │ ✓      │
│ SearchPlaceholder  │ it       │ Cerca pazienti                      │ ✓      │
╰────────────────────┴──────────┴─────────────────────────────────────┴────────╯

Translated 12 of 12 items.

12 keys translated in seconds. Done.

The CLI uses colorized output - missing translations show in red, complete in green.

Quality Comparison

"But is the quality good enough?"

I compared Ollama (llama3.2) vs Google Translate vs DeepL for my app strings:

Provider	Quality	Cost	Speed
DeepL	Excellent	$20/mo	Fast
Google	Very Good	Pay-per-use	Fast
Ollama (llama3.2)	Good	$0	Medium
MyMemory	Good	$0	Fast

For UI strings like "Save", "Cancel", "Error occurred"? Ollama is more than good enough.

For marketing copy or legal text? Maybe pay for DeepL.

For 90% of app localization? Free works fine.

More Than Just Translation

Once I built the translation part, I kept going. LRM now does:

# Validate resource files (find issues)
lrm validate

⚠ Validation found 12 issue(s)

                                  Empty Values
┌──────────┬───────────────────────────────────────────────────────────────────┐
│ Language │ Empty Keys                                                        │
├──────────┼───────────────────────────────────────────────────────────────────┤
│ de       │ CancelButton, DeleteConfirmation, ErrorOccurred, PatientName...   │
│ fr       │ ErrorOccurred, PatientName, AppointmentDate, NoResultsFound...    │
└──────────┴───────────────────────────────────────────────────────────────────┘

Find Dead Code (.NET only)

This one's a game-changer. LRM scans your C#, Razor, and XAML files to find:

Missing keys - used in code but not defined in .resx (runtime errors waiting to happen!)
Unused keys - defined in .resx but never used in code (dead translations)

lrm scan --source-path ./src

✓ Scanned 3 files
Found 18 key references (16 unique keys)

              Missing Keys (in code, not in .resx)
╭─────────────────────┬────────────┬───────────────────────────╮
│ Key                 │ References │ Locations                 │
├─────────────────────┼────────────┼───────────────────────────┤
│ AboutUs             │ 1          │ HomeController.cs:31      │
│ AppSubtitle         │ 1          │ HomeController.cs:22      │
│ CompanyDescription  │ 1          │ HomeController.cs:32      │
│ GetStarted          │ 1          │ Index.cshtml:9            │
│ OperationFailed     │ 1          │ NotificationService.cs:23 │
│ OperationSuccessful │ 1          │ NotificationService.cs:17 │
│ ... and 7 more      │            │                           │
╰─────────────────────┴────────────┴───────────────────────────╯

✗ Found 13 missing keys and 2 unused keys

13 keys used in code that don't exist in my .resx files! Those would be runtime errors. Now I can add them before users see broken UI.

On a larger project (my actual app), the scan also found the opposite:

✓ Scanned 497 files
Found 607 key references (394 unique keys)

 Unused Keys (in .resx, not in code)
╭────────────────────────────┬───────╮
│ Key                        │ Count │
├────────────────────────────┼───────┤
│ ActiveAdmissions           │ -     │
│ AdmissionCount             │ -     │
│ DailyAdmissions            │ -     │
│ LanguageAutoDetect         │ -     │
│ MarkAsComplete             │ -     │
│ ... and 51 more            │       │
╰────────────────────────────┴───────╯

✗ Found 0 missing keys and 56 unused keys

56 dead keys I can clean up. Less clutter, smaller resource files.

More Tools

# Interactive editor (TUI)
lrm edit

# Convert between formats
lrm convert --from resx --to json

# Export for translators
lrm export --format csv

Works With Your Stack

LRM supports what you're already using:

.resx (WPF, WinForms, ASP.NET)
JSON (ASP.NET Core, Blazor)
i18next (React, Vue, Angular)
Android strings.xml
iOS .strings

All formats, one tool.

The Workflow That Actually Works

Here's my complete localization workflow now:

# 1. Add new English strings normally in your app

# 2. Validate (catch issues early)
lrm validate

# 3. Translate missing keys
lrm translate --only-missing --provider ollama

# 4. Quick review in TUI
lrm edit

# 5. Commit
git add Resources/
git commit -m "Add translations"

Total time: 5 minutes. Total cost: $0.

Why I Open-Sourced It

I built this for myself. Then I realized other solo devs have the same problem.

So I open-sourced it: github.com/nickprotop/LocalizationManager

MIT License (use it however you want)
Works 100% offline
No accounts, no tracking
Self-host everything

From Side Project to Product

What started as "I need to translate my app" grew into something bigger. The CLI worked so well that I kept adding features. Then I built a web UI. Then cloud sync. Then OTA updates.

Now it's a full platform: lrm-cloud.com

The cloud adds what solo devs need when they grow:

Format agnostic - One project syncs to RESX, JSON, or i18next
Web editor - Edit translations from anywhere, no CLI needed
OTA updates - Update translations without redeploying (first OTA for .NET!)
GitHub sync - Bidirectional sync with your repo
Translation Memory - Reuses past translations, saves API costs
Glossary - Enforce consistent terminology
Invite translators - They edit in browser, you review and approve
Free tier - 3 projects, 5K chars/month - enough for side projects

But here's the thing: the CLI is still 100% free and open source. The cloud is optional - and self-hosted if you want!

I'm not ashamed of building a product from solving my own problem. That's how the best tools get built. You scratch your own itch, then share the solution.

TL;DR

# Install (Linux)
curl -sSL https://raw.githubusercontent.com/nickprotop/LocalizationManager/main/install-lrm.sh | bash
ollama pull llama3.2

# Translate your app for free
cd YourProject/Resources
lrm translate --only-missing --provider ollama --target-languages es,fr,de,it,pt

# Done. $0. 5 minutes.

Got questions? Open an issue on GitHub or find me on Reddit.

Found it useful? A GitHub star helps others discover it.

Tags: dotnet, localization, i18n, translation, ollama, llm, open-source, csharp, blazor, aspnetcore

Automating .NET Localization: From Code Scan to Auto-Translate to Pull Request

Nikolaos Protopapas — Fri, 14 Nov 2025 21:34:56 +0000

A cross-platform CLI/TUI for managing .resx files with free AI translation, code scanning, and CI/CD automation

The Problem Every .NET Developer Faces

You've built a great .NET application. Now you need to support multiple languages. You create your first .resx file, add some keys, and everything works beautifully in English. Then the requests come in: "Can we support French? German? Greek?"

You create Resources.fr.resx, copy all the keys, send them to a translator, paste the translations back... and your build breaks. An XML tag got corrupted. A key is missing. A duplicate slipped in. You're now manually diff-ing XML files trying to figure out what went wrong.

If you're on Linux or macOS, it's even worse. Visual Studio's ResX Resource Manager? Windows-only. Editing XML by hand? Error-prone and painful. You end up writing bash scripts that barely work, or worse, you spin up a Windows VM just to manage resource files.

There had to be a better way.

Understanding .NET Localization: The Foundation

Before we dive into the solution, let's understand how .NET actually handles localization. If you've ever wondered what those .resx files really are and how they work at runtime, this section is for you.

What Are .resx Files?

Resource files (.resx) are XML-based files that store localized strings, images, and other resources. Here's what a typical resource file looks like:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="WelcomeMessage" xml:space="preserve">
    <value>Welcome to our application!</value>
    <comment>Shown on the home page</comment>
  </data>
  <data name="SaveButton" xml:space="preserve">
    <value>Save</value>
  </data>
  <data name="CancelButton" xml:space="preserve">
    <value>Cancel</value>
  </data>
</root>

Each <data> element contains:

name: The key you use in code
value: The translated text
comment (optional): Context for translators

The Resource File Naming Convention

.NET uses a specific naming convention to organize translations:

Resources/
├── SharedResources.resx          ← Default/invariant culture (usually English)
├── SharedResources.fr.resx       ← French
├── SharedResources.de.resx       ← German
├── SharedResources.el.resx       ← Greek
└── SharedResources.fr-CA.resx    ← French Canadian (specific culture)

The pattern is simple: {BaseName}.{culture-code}.resx

How the ResourceManager Works

When your application runs, .NET's ResourceManager automatically loads the correct resource file based on the current culture:

User's Culture: fr-CA (French Canadian)
                  │
                  ↓
         Look for: SharedResources.fr-CA.resx
                  │
                  ↓ (not found)
         Fall back to: SharedResources.fr.resx
                  │
                  ↓ (not found)
         Fall back to: SharedResources.resx (default)

This fallback mechanism ensures users always see something, even if a specific translation is missing. But it also means missing translations can go unnoticed until production.

The Culture Fallback Chain

┌─────────────────────────────────────────────────────────┐
│  Application Runtime                                    │
│                                                         │
│  CurrentUICulture: "el-GR" (Greek - Greece)             │
└────────────────────┬────────────────────────────────────┘
                     │
                     ↓
        ┌─────────────────────────────────────────────────┐
        │ ResourceManager.GetString("WelcomeMessage")     │
        └────────────┬────────────────────────────────────┘
                     │
                     ↓
        ┌─────────────────────────────────────────────────┐
        │ 1. Try: Resources.el-GR.resx                    │
        │     File not found                              │
        └────────────┬────────────────────────────────────┘
                     │
                     ↓
        ┌─────────────────────────────────────────────────┐
        │ 2. Try: Resources.el.resx                       │
        │     Found! Return Greek translation             │
        └─────────────────────────────────────────────────┘
                     │
                     ↓ (if not found)
        ┌─────────────────────────────────────────────────┐
        │ 3. Fallback: Resources.resx                     │
        │     Return default (English)                    │
        └─────────────────────────────────────────────────┘

Common Pain Points in .NET Localization

Through building LocalizationManager, I encountered (and solved) these recurring issues:

XML Corruption: One misplaced < or & breaks your entire build
Missing Translations: Keys exist in the default file but not in translated files
Duplicate Keys: Same key defined twice = build error
Empty Values: Is an empty <value></value> intentional or a mistake?
Sync Issues: You add a key to Resources.resx but forget to add it to all language files
No Validation: You only discover issues when the build fails
Manual Translation: Expensive, slow, and doesn't scale

Why Existing Tools Fall Short

Visual Studio: Windows-only, requires full IDE installation
ResX Resource Manager: Excellent tool, but also Windows-only
Manual XML Editing: Works everywhere, but error-prone and lacks validation
Online Tools: Require uploading sensitive data, no local workflow integration
Custom Scripts: Everyone reinvents the wheel poorly

The gap was clear: We needed a cross-platform, command-line-first tool that could handle the entire localization workflow from validation to automated translation to CI/CD integration.

The Solution: LocalizationManager

I built LocalizationManager (lrm) to be the tool I wished existed when I started working with .NET localization on Linux.

Core Philosophy

Cross-platform first: Native binaries for Linux, Windows, macOS, including ARM64
CLI-first, with a bonus TUI: Perfect for automation and CI/CD, but also great for interactive use
Complete workflow: Not just a translator, but the entire pipeline
Modern approach: AI translation with caching, smart batch processing
Developer-friendly: JSON output, exit codes, extensive documentation

Key Features at a Glance

✅ Validation: Detect missing translations, duplicates, XML errors
📊 Statistics: Translation coverage with progress bars
🔍 Code Scanning: Find unused keys and missing references in your source code
🌐 Auto-Translation: 7 providers including Google, DeepL, OpenAI, Claude, and local Ollama
📺 Interactive TUI: Visual editing with keyboard shortcuts
🚀 CI/CD Ready: JSON output, exit codes, GitHub Actions integration
💾 Import/Export: CSV format for working with translators
📝 Full CLI: 15+ commands for every localization task

Architecture & Technical Design

Let me share some of the key architectural decisions that make LocalizationManager work well.

Technology Stack

Language: C# / .NET 9.0
TUI Framework: Spectre.Console (amazing for rich terminal interfaces)
CLI Framework: Spectre.Console.Cli (command routing and parsing)
Translation APIs: Native HTTP clients (no heavy SDK dependencies)
Caching: SQLite for translation cache
Packaging: Self-contained single-file executables

Translation Provider Architecture

One of the most important design decisions was creating an abstraction for translation providers. This allows users to choose the best provider for their needs while keeping the code maintainable.

┌─────────────────────────────────────────────────────────────┐
│                   TranslationProviderFactory                │
│                                                             │
│  Create(providerName) → ITranslationProvider                │
└───────────────────┬─────────────────────────────────────────┘
                    │
        ┌───────────┴───────────┬──────────────┬──────────────┐
        ↓                       ↓              ↓              ↓
┌───────────────┐    ┌───────────────┐  ┌──────────┐  ┌──────────┐
│ GoogleProvider│    │  DeepLProvider│  │ Ollama   │  │ OpenAI   │
│               │    │               │  │ Provider │  │ Provider │
│ - Translate   │    │ - Translate   │  │          │  │          │
│ - Batch       │    │ - Batch       │  │ - Local  │  │ - GPT-4  │
│ - Cache       │    │ - Cache       │  │ - Free   │  │ - Claude │
└───────────────┘    └───────────────┘  └──────────┘  └──────────┘
        │                       │              │              │
        └───────────────────────┴──────────────┴──────────────┘
                                │
                   ┌────────────▼─────────────┐
                   │    TranslationCache      │
                   │    (SQLite, 30-day)      │
                   │                          │
                   │  - Reduces API costs     │
                   │  - Provider-specific     │
                   │  - SHA-256 cache keys    │
                   └──────────────────────────┘

Key Benefits:

Add new providers without changing existing code
Each provider handles its own rate limiting
Centralized caching reduces costs by 80%+
Providers can be traditional (Google) or AI-powered (Claude)

Using the Translation System

Switch between providers and control translation behavior:

# Translate all missing keys
lrm translate --only-missing --provider google

# Use specific provider
lrm translate --provider ollama  # Free local translation
lrm translate --provider deepl   # High quality

# Target specific languages only
lrm translate --target-languages fr,de,es --provider google

# Re-translate specific keys
lrm translate "Error*" --provider deepl --overwrite

# Preview before saving
lrm translate --only-missing --dry-run

# Batch control for rate limiting
lrm translate --batch-size 5 --provider google

Key options:

--provider - google, deepl, openai, claude, ollama, libretranslate, azureopenai, azuretranslator
--only-missing - Skip keys with existing translations
--target-languages - Comma-separated language codes (fr,de,es)
--overwrite - Allow re-translating existing values (use with key pattern)
--dry-run - Preview without saving
--batch-size - Control concurrent API calls
--no-cache - Bypass the 30-day SQLite cache

Caching: All translations cached 30 days in ~/.local/share/LocalizationManager/translations.db, reducing API costs by 80%+.

The AI Translation Revolution

Here's something exciting: we added support for modern AI translation providers alongside traditional machine translation services.

Provider Comparison:

Provider	Type	Quality	Privacy	API Key Required
Google Translate	Traditional MT	High	Cloud	Yes
DeepL	Traditional MT	Highest (EU)	Cloud	Yes
LibreTranslate	Traditional MT	Good	Self-host	Optional
OpenAI GPT	AI (LLM)	Excellent	Cloud	Yes
Claude	AI (LLM)	Excellent	Cloud	Yes
Ollama	AI (Local LLM)	Very Good	Local	No
Azure OpenAI	AI (LLM)	Excellent	Enterprise	Yes

Why AI Translation Matters:

Context Awareness: LLMs understand context better than traditional MT
Technical Terminology: Better at preserving technical terms and code snippets
Tone Preservation: Maintains the original tone (formal, casual, technical)
Free Option: Ollama runs locally for free with surprisingly good results
Privacy: With Ollama, your data never leaves your machine

Code Scanning: Keeping Code and Resources in Sync

One unique feature is the code scanner that analyzes your source code to find localization key usage:

# Scan C#, Razor, XAML files for key usage
lrm scan --source-path ./src --format json

# Output shows:
# ✓ Scanned 245 files
# Found 156 key references
# ⚠ 3 keys used in code but missing from .resx
# ⚠ 12 keys in .resx but never used

The scanner detects patterns like:

Resources.WelcomeMessage
GetString("SaveButton")
Translate("ErrorText")
{x:Static res:Strings.PageTitle} (XAML)
@Resources.Message (Razor)

The scan command reports the issues - you then use other commands to fix them:

# 1. Scan and save results
lrm scan --format json > scan-results.json

# 2. Add missing keys interactively (prompts for proper values)
jq -r '.missingKeys[]?.key // empty' scan-results.json | while read key; do
  lrm add "$key" -i  # Interactive mode - prompts for values in each language
done

# OR: Add as placeholders for manual review later
jq -r '.missingKeys[]?.key // empty' scan-results.json | while read key; do
  lrm add "$key" --lang default:"$key" --comment "TODO: Add proper text (from code scan)"
done
# ⚠️ Important: Edit .resx files to add proper English text before running translate!

# 3. After adding proper values, then translate
lrm translate --only-missing

This helps prevent:

Dead keys in resource files (unused keys)
Missing keys that will fail at runtime
Localization drift over time

The Complete Workflow: From Chaos to Automation

Here's the workflow that LocalizationManager enables, from manual pain to full automation:

Before: The Manual Nightmare

Developer adds English string
    ↓
Export .resx to Excel/CSV somehow
    ↓
Email to translator (wait 3 days)
    ↓
Receive translated Excel/CSV
    ↓
Manually copy-paste into .resx files
    ↓
Build fails (XML corruption)
    ↓
Fix XML manually
    ↓
Build succeeds, but French is missing 3 keys
    ↓
Repeat entire process for those 3 keys
    ↓
Week wasted

After: The Automated Flow

┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 1: VALIDATE                                            │
│  ├─ Check XML syntax                                         │
│  ├─ Find duplicate keys                                      │
│  └─ Detect empty values                                      │
│                                                              │
└────────────────┬─────────────────────────────────────────────┘
                 ↓
┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 2: SCAN CODE (optional)                                │
│  ├─ Find keys used in source files                           │
│  ├─ Detect missing keys (in code but not in .resx)           │
│  ├─ Detect unused keys (in .resx but not in code)            │
│  └─ Generate JSON report for processing                      │
│                                                              │
└────────────────┬─────────────────────────────────────────────┘
                 ↓
┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 2a: ADD MISSING KEYS (if scan found any)               │
│  ├─ Parse scan results JSON                                  │
│  ├─ Use 'lrm add' command for each missing key               │
│  └─ Keys now added to default .resx file                     │
│                                                              │
└────────────────┬─────────────────────────────────────────────┘
                 ↓
┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 3: CHECK MISSING                                       │
│  ├─ Find untranslated keys                                   │
│  ├─ Generate report per language                             │
│  └─ Count: 47 keys need translation                          │
│                                                              │
└────────────────┬─────────────────────────────────────────────┘
                 ↓
┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 4: AUTO-TRANSLATE                                      │
│  ├─ Batch translate missing keys                             │
│  ├─ Use cache for repeated strings                           │
│  ├─ Apply rate limiting                                      │
│  └─ Result: 47/47 translations completed                     │
│                                                              │
└────────────────┬─────────────────────────────────────────────┘
                 ↓
┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 5: RE-VALIDATE                                         │
│  ├─ Verify all XML is still valid                            │
│  ├─ Confirm no keys were corrupted                           │
│  └─ Status: All checks passed                                │
│                                                              │
└────────────────┬─────────────────────────────────────────────┘
                 ↓
┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Step 6: COMMIT & PR                                         │
│  ├─ Git commit with detailed message                         │
│  ├─ Create pull request                                      │
│  └─ Time elapsed: 2 minutes                                  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Running the Workflow: Five Ways

Choose the approach that matches your team's needs:

Manual CLI - Step-by-step learning and exploration
Bash Script A - Auto-translate existing keys with proper values
Bash Script B - Scan code and add placeholders for review
Ollama (Free!) - Private local translation, zero cost 🆓
Duplicate Cleanup - Merge or delete duplicate keys

1. Manual CLI (step by step):

# Step 1: Validate
lrm validate --path ./Resources

# Step 2: Check what's missing
lrm validate --missing-only --format json > missing.json

# Step 3: Translate only what's missing
lrm translate --only-missing --provider openai

# Step 4: Verify
lrm validate

2. Automated Script (Option A - Translate Existing Keys):

#!/bin/bash
# Workflow for auto-translating keys that already have proper English text
set -e

# Validate
lrm validate

# Translate missing translations
lrm translate --only-missing --provider google

# Final validation
lrm validate

# Commit and create PR
git add Resources/
git commit -m "🌐 Auto-translate missing localization keys"
gh pr create --title "Auto-translate localizations"

2b. Automated Script (Option B - Scan and Add Keys for Review):

#!/bin/bash
# Workflow for scanning code and adding placeholder keys that need manual review
set -e

# Validate
lrm validate

# Scan code and add missing keys
lrm scan --source-path ./src --format json > scan-results.json
if [ -s scan-results.json ]; then
  jq -r '.missingKeys[]?.key // empty' scan-results.json | while read key; do
    [ -n "$key" ] && lrm add --key "$key" --value "$key" --comment "TODO: Add proper English text (from code scan)"
  done
fi

# Final validation
lrm validate

# Commit and create PR for manual review
git add Resources/
git commit -m "📋 Add placeholder keys from code scan - manual review required"
gh pr create --title "Review and add text for new localization keys" --body "⚠️ These keys were added with placeholder values. Please edit the .resx files to add proper English text before running auto-translation."

⚠️ Important: Option B adds keys with placeholder values (key name as the value). Do NOT run lrm translate until after manually editing the .resx files to add proper English text. Otherwise, it will translate the placeholder "WelcomeMessage" literally instead of your intended English message.

3a. GitHub Actions - Translate Existing Keys:

name: Auto-Translate Existing Keys

on:
  push:
    paths: ['Resources/**/*.resx']  # Only .resx changes

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup LRM
        run: |
          wget https://github.com/nickprotop/LocalizationManager/releases/latest/download/lrm-linux-x64.tar.gz
          tar -xzf lrm-linux-x64.tar.gz
          chmod +x linux-x64/lrm
          echo "$PWD/linux-x64" >> $GITHUB_PATH

      - name: Validate → Translate → Validate
        env:
          LRM_OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          # Validate
          lrm validate

          # Translate all missing translations
          lrm translate --only-missing --provider openai

          # Final validation
          lrm validate

      - name: Commit Changes
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add Resources/
          git commit -m "🌐 Auto-translate missing localization keys" || echo "No changes"
          git push

3b. GitHub Actions - Scan and Add Placeholders:

name: Scan Code and Add Placeholders

on:
  push:
    paths: ['src/**/*.cs']  # Only code changes

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - name: Setup LRM
        run: |
          wget https://github.com/nickprotop/LocalizationManager/releases/latest/download/lrm-linux-x64.tar.gz
          tar -xzf lrm-linux-x64.tar.gz
          chmod +x linux-x64/lrm
          echo "$PWD/linux-x64" >> $GITHUB_PATH

      - name: Scan → Add → Create PR
        run: |
          # Validate
          lrm validate

          # Scan code for missing keys
          lrm scan --source-path ./src --format json > scan-results.json

          # Add missing keys found in code
          jq -r '.missingKeys[]?.key // empty' scan-results.json | while read key; do
            if [ -n "$key" ]; then
              lrm add --key "$key" --value "$key" --comment "TODO: Add proper English text (from code scan)"
            fi
          done

          # Validate additions
          lrm validate

      - name: Create PR for Review
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git checkout -b scan/add-keys-$(date +%s)
          git add Resources/
          git commit -m "📋 Add placeholder keys from code scan" || exit 0
          git push --set-upstream origin HEAD

          gh pr create \
            --title "Review: Add proper text for new localization keys" \
            --body "⚠️ **Manual Review Required**

          These keys were added with placeholder values (key name as value).

          **Next steps:**
          1. Edit the .resx files to replace placeholder values with proper English text
          2. After merging, the auto-translate workflow will handle other languages"

⚠️ Important: These are two separate workflows. Workflow 3a handles translation of keys that already have proper English text. Workflow 3b adds new keys found in code but does NOT translate them - it creates a PR for manual review first.

4. Privacy-First Local Translation (Zero Cost with Ollama):

The best translation is free! Use Ollama to translate locally without cloud APIs:

#!/bin/bash
# One-time setup: Install Ollama and pull a model
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2

# Validate resources
lrm validate

# Translate locally - no cloud, no cost, no data leaving your machine
lrm translate --only-missing --provider ollama

# Validate
lrm validate

Why Ollama is amazing:

💰 $0 cost - Unlimited translations forever
🔒 Complete privacy - Data never leaves your machine
✈️ Works offline - No internet required after model download
🔑 No API keys - One less secret to manage
🎯 Good quality - llama3.2 handles technical UI text well
⚖️ GDPR/HIPAA friendly - Perfect for sensitive data

Perfect for:

Medical records UI (HIPAA compliance)
Banking applications (PCI/SOX compliance)
Internal tools (security policies)
Bootstrapped projects (zero budget)
High-volume needs (no quota limits)

5. Clean Up Duplicate Keys (Merge or Delete):

Resource files can accumulate duplicate keys from merges, imports, or accidents. LRM helps clean them up:

#!/bin/bash
# Step 1: Detect duplicates
lrm validate --format json > validation.json

duplicate_count=$(jq '[.issues[]? | select(.type=="Duplicate")] | length' validation.json)

if [ "$duplicate_count" -gt 0 ]; then
  echo "⚠️  Found $duplicate_count duplicate keys"

  # Step 2: View duplicates
  lrm validate  # Shows table with duplicate warnings

  # Step 3: Choose your cleanup strategy

  # Option A: Merge interactively (choose which value to keep per language)
  lrm merge-duplicates ErrorMessage
  # Shows:
  # ErrorMessage [1]: "An error occurred"
  # ErrorMessage [2]: "Error occurred"
  # Which to keep for default language? [1/2]: 1
  # (repeats for each language)

  # Option B: Auto-merge keeping first occurrence
  lrm merge-duplicates ErrorMessage --auto-first -y

  # Option C: Merge ALL duplicates at once (keeps first of each)
  lrm merge-duplicates --all --auto-first -y

  # Option D: Delete all occurrences entirely
  lrm delete ErrorMessage --all-duplicates -y

  # Step 4: Validate cleanup
  lrm validate
  echo "✅ Duplicates cleaned up"
fi

Common scenarios that create duplicates:

❌ Git merge conflicts in .resx files
❌ Importing CSV files with existing keys
❌ Manual XML editing mistakes
❌ Merging resource files from different branches

Interactive merge example:

$ lrm merge-duplicates WelcomeMessage

Found 2 occurrences of 'WelcomeMessage':

Default language:
  [1] "Welcome to our app!"
  [2] "Welcome to our application!"

Which to keep? [1/2]: 1

French (fr):
  [1] "Bienvenue dans notre app !"
  [2] "Bienvenue dans notre application !"

Which to keep? [1/2]: 2

✓ Merged WelcomeMessage: kept occurrence 1 for default, occurrence 2 for fr

Pro tip: Always validate after cleanup to ensure no issues remain!

Real-World Usage Examples

Let's see LocalizationManager in action with real examples.

Installation (One Command)

# Linux/macOS
curl -sSL https://raw.githubusercontent.com/nickprotop/LocalizationManager/main/install-lrm.sh | bash

# Windows (PowerShell)
iwr -useb https://raw.githubusercontent.com/nickprotop/LocalizationManager/main/install-lrm.ps1 | iex

That's it. No dependencies, no .NET SDK required. Self-contained binary.

Basic Workflow

# Navigate to your Resources folder
cd MyApp/Resources

# Check current status
lrm stats

# Output:
# ┌──────────────────┬───────┬──────────┬───────────┐
# │ Language         │ Keys  │ Coverage │ File Size │
# ├──────────────────┼───────┼──────────┼───────────┤
# │ English (en)     │ 252   │ 100.0%   │ 45.2 KB   │
# │ French (fr)      │ 245   │  97.2%   │ 43.1 KB   │
# │ German (de)      │ 238   │  94.4%   │ 41.8 KB   │
# │ Greek (el)       │ 252   │ 100.0%   │ 46.3 KB   │
# └──────────────────┴───────┴──────────┴───────────┘

# Translate missing French and German keys
lrm translate --only-missing --target-languages fr,de --provider openai

# Output:
# 🌐 Translating 14 keys to 2 languages...
# ✓ fr: 7/7 keys translated
# ✓ de: 7/7 keys translated
# ✓ Translations saved
# ⚡ Used cache for 3 translations

Interactive TUI Mode

# Launch the Terminal UI
lrm edit

╔═══════════════════════════════════════════════════════════╗
║  LocalizationManager - Interactive Editor                 ║
╠═══════════════════════════════════════════════════════════╣
║                                                           ║
║  Key: WelcomeMessage                                      ║
║  ┌─────────────────────────────────────────────────────┐  ║
║  │ Default (en): Welcome to our application!           │  ║
║  │ French (fr):  Bienvenue dans notre application!     │  ║
║  │ German (de):  Willkommen in unserer Anwendung!      │  ║
║  │ Greek (el):   Καλώς ήρθατε στην εφαρμογή μας!       │  ║
║  └─────────────────────────────────────────────────────┘  ║
║                                                           ║
║  [Ctrl+T] Translate  [Ctrl+S] Save  [Ctrl+Q] Quit         ║
╚═══════════════════════════════════════════════════════════╝

AI Translation Comparison

Let's translate a technical string with different providers:

Source (English):

"Click the Save button to persist your changes to the database."

Traditional MT (Google Translate) → French:

"Cliquez sur le bouton Enregistrer pour conserver vos modifications dans la base de données."

Accurate but mechanical

AI (GPT-4o-mini) → French:

"Cliquez sur le bouton Enregistrer pour sauvegarder vos modifications dans la base de données."

More natural, preserves "Save" as "Enregistrer" (common UI term)

AI (Claude) → French:

"Cliquez sur le bouton Enregistrer pour sauvegarder définitivement vos modifications dans la base de données."

Adds "définitivement" (permanently) - excellent context awareness

Provider Features:

Traditional APIs: Consistent quality, proven reliability
AI (Cloud): Excellent context awareness, requires API key
Ollama (Local): Free to use, runs on your machine, no API key needed ⭐

Configuration for AI Providers

Create lrm.json in your Resources folder:

{
  "defaultLanguageCode": "en",
  "translation": {
    "defaultProvider": "openai",
    "aiProviders": {
      "openai": {
        "model": "gpt-4o-mini",
        "customSystemPrompt": "Translate UI text naturally, preserve technical terms",
        "rateLimitPerMinute": 60
      },
      "ollama": {
        "apiUrl": "http://localhost:11434",
        "model": "llama3.2",
        "rateLimitPerMinute": 10
      }
    }
  }
}

Set your API keys:

# Via environment variables (recommended)
export LRM_OPENAI_API_KEY="sk-..."
export LRM_CLAUDE_API_KEY="sk-ant-..."

# Or via secure credential store
lrm config set-api-key --provider openai --key "sk-..."

# Ollama needs no API key!

Architecture Highlights: Why It Works

1. Self-Contained Binaries

Using .NET's publishing options, LocalizationManager compiles to a single, self-contained executable:

No .NET runtime installation required
No dependencies to manage
~50MB binary includes everything
Fast startup (~100ms)

2. Cross-Platform Terminal UI

Spectre.Console makes the TUI work beautifully on all platforms:

Windows Command Prompt  ✓
Windows Terminal       ✓
PowerShell            ✓
Linux Terminal        ✓
macOS Terminal        ✓
SSH Sessions          ✓

3. JSON Output for Automation

Every command supports --format json for easy parsing:

lrm validate --format json | jq '.isValid'
# true

lrm stats --format json | jq '.statistics[].coverage'
# 100.0
# 97.2
# 94.4

Perfect for:

CI/CD pipelines
Custom dashboards
Monitoring and alerts
Integration with other tools

4. Intelligent Rate Limiting

Each translation provider has configurable rate limits to avoid hitting API quotas:

// Automatic rate limiting
public class RateLimiter
{
    private readonly int _requestsPerMinute;

    public async Task WaitAsync()
    {
        // Automatically throttles requests
        // Tracks request times in sliding window
        // Prevents API rate limit errors
    }
}

5. Batch Processing with Fallback

Translations are processed in batches when providers support it:

// Try batch translation first
var batchResult = await TranslateBatchAsync(requests);

// Fall back to individual translation if batch fails
if (batchResult.HasErrors)
{
    foreach (var request in failedRequests)
    {
        await TranslateAsync(request);
    }
}

Getting Started

Try It Now

# Install
curl -sSL https://raw.githubusercontent.com/nickprotop/LocalizationManager/main/install-lrm.sh | bash

# Go to your Resources folder
cd YourProject/Resources

# Check status
lrm stats

# Validate everything
lrm validate

# Start interactive mode
lrm edit

Next Steps

Read the docs: Full documentation
Star on GitHub: GitHub Repository
Try the workflow: Follow the Quick Start guide
Set up CI/CD: Check out the CI/CD examples
Join the community: Report issues, request features, contribute!

Contributing

LocalizationManager is MIT licensed and welcomes contributions:

🐛 Bug reports: Found an issue? Let us know!
✨ Feature requests: Have an idea? Open a discussion!
🔧 Pull requests: Code contributions welcome!
📖 Documentation: Help improve the docs!

Conclusion: Making .NET Localization Painless

LocalizationManager started as a personal itch I needed to scratch: managing .resx files on Linux without Windows tools. It evolved into a comprehensive solution that:

✅ Works on any platform (Linux, Windows, macOS, ARM64)
✅ Automates the complete workflow (validate → translate → commit → PR)
✅ Integrates modern AI translation (OpenAI, Claude, Ollama)
✅ Smart caching reduces redundant API calls
✅ Provides both CLI and TUI for automation and interactive use
✅ Scans your source code to keep resources in sync
✅ Integrates seamlessly with CI/CD pipelines

Whether you're a solo developer managing translations for a side project or a team handling enterprise-scale localization, LocalizationManager provides the tools you need to work efficiently.

The best part? It's completely free and open source. No subscriptions, no locked features, no vendor lock-in. Just a tool that works.

Links & Resources

GitHub Repository: https://github.com/nickprotop/LocalizationManager
Documentation: https://github.com/nickprotop/LocalizationManager/tree/main/docs
Installation Guide: https://github.com/nickprotop/LocalizationManager/docs/INSTALLATION.md
CI/CD Examples: https://github.com/nickprotop/LocalizationManager/docs/CICD.md
Translation Guide: https://github.com/nickprotop/LocalizationManager/docs/TRANSLATION.md
Issue Tracker: https://github.com/nickprotop/LocalizationManager/issues

Built with ❤️ by Nikolaos Protopapas
Licensed under MIT - Free to use, modify, and distribute

Did you find this article helpful? Please share it with your fellow .NET developers!

Tags: #dotnet #devops #opensource #localization #ai #linux #translation #csharp #cli #automation

Terminal UI for .NET .resx Files Because Nothing Else Worked

Nikolaos Protopapas — Sun, 09 Nov 2025 16:59:47 +0000

There Was No Way to Manage .NET Localization from the Console, So I Built One

I work primarily in a Linux terminal. SSH into my dev box, tmux sessions, vim, the works. When I started building a .NET WASM application with a .NET API server, I knew I'd need localization support from the start—English and Greek.

That's when I discovered a glaring gap in the .NET ecosystem: there's no proper command-line tool for managing .resx localization files.

The Problem: Localization Tooling is GUI-Only

Here's what's available for managing .resx files in .NET:

Visual Studio - Windows only, GUI only, requires gigabytes of disk space
Rider - Another GUI-only IDE
VS Code - No decent extension for .resx files
ResXResourceManager - Excellent tool, but Windows-only GUI
Manual XML editing - Good luck with XML namespaces and encoding

For someone who:

Develops on a Linux box
Lives in the terminal
Works exclusively over SSH
Needs to add localization to a WASM app

...none of these options work.

The Moment of Realization

I was adding Greek language support to my application. Simple task, right? Add Resources.el.resx, copy the keys from Resources.resx, translate the values.

But how do I actually do this from my terminal?

Option 1: Manual XML editing

vim Resources.el.resx
# Now manually replicate the XML structure
# Copy each <data> element
# Hope you don't mess up the encoding
# Pray you don't introduce XML syntax errors

No. Just no.

Option 2: Write a script

So I wrote a Python script. Then I needed to validate both files. Wrote another script. Then I needed to add a new key to both languages. Modified the script again.

After the third time writing variations of "quick scripts" for basic operations, I realized: this is a fundamental workflow gap.

What I Actually Needed

I wanted a Visual Studio-like experience, but from the command line. Something that could:

Work entirely in the terminal
Work over SSH (no GUI)
Add, update, delete keys across all languages atomically
Validate completeness and correctness
Let me edit translations interactively without leaving the terminal
Be future-proof for when I eventually work with translators

The vision was clear: modern CLI tooling with an interactive TUI, built specifically for .resx management on Linux.

Why This Gap Exists

.NET is genuinely cross-platform now. You can build WASM apps, API servers, microservices—all on Linux with no issues. But the tooling ecosystem is still catching up.

Most .NET localization tools assume:

You're on Windows
You have a GUI available
You want to use an IDE

But modern development—especially on Linux—is increasingly terminal-first. SSH into a VPS, work in tmux, use terminal tools. It's faster, cleaner, and works everywhere.

The .NET ecosystem just didn't have tooling for this workflow.

So I Built LRM

After realizing I'd be writing throwaway scripts forever, I decided to build a proper tool.

Core requirements:

✅ Native Linux support (no Mono, no Wine, just .NET)
✅ Command-line first (scriptable, automatable)
✅ Interactive TUI (Visual Studio-like experience in terminal)
✅ Works over SSH (no GUI dependencies)
✅ Full CRUD operations (add, update, delete keys)
✅ Validation (detect missing keys, duplicates, empty values)
✅ Future-proof (CSV import/export for translators)
✅ Fast and self-contained (no runtime dependencies)

The result is Localization Resource Manager (LRM)—a modern CLI tool with an interactive Terminal UI for managing .resx files from the command line.

Real Workflow: Adding Greek Support

Before LRM:

# Copy the file
cp Resources.resx Resources.el.resx

# Open in vim and manually translate 200+ strings
vim Resources.el.resx
# Edit XML by hand... for hours

# No way to validate I got everything
# No way to check for consistency
# Pure manual labor

With LRM:

# Add Greek language file
lrm add-language --culture el --copy-from default

# See what needs translation
lrm stats
# ┌──────────────────┬───────┬──────────┐
# │ Language         │ Keys  │ Coverage │
# ├──────────────────┼───────┼──────────┤
# │ English (Default)│ 203   │ 100.0%   │
# │ Ελληνικά (el)    │ 203   │ 100.0%   │ (copied)
# └──────────────────┴───────┴──────────┘

# Edit translations interactively
lrm edit
# [TUI opens, side-by-side view of English/Greek]
# Search, navigate, edit, save
# All from the terminal

# Validate everything is correct
lrm validate
# ✓ All validations passed

This is the workflow I wanted from day one.

The Terminal UI: Visual Studio Experience in SSH

One of my favorite features is the interactive TUI. Run lrm edit and you get a full-featured editor right in your terminal:

┌────────────────────────────────────────────────────────────────┐
│ File  Edit  Languages  Help                                    │
├────────────────────────────────────────────────────────────────┤
│ Search: [save_______________]   Ctrl+N=Add  F2=Language  F6=Val│
├──────────────┬────────────────────────┬────────────────────────┤
│ Key          │ English (Default)      │ Ελληνικά (el)          │
├──────────────┼────────────────────────┼────────────────────────┤
│ SaveButton   │ Save                   │ Αποθήκευση             │
│ CancelButton │ Cancel                 │ Ακύρωση                │
│ DeleteButton │ Delete                 │ Διαγραφή               │
│ ...          │ ...                    │ ...                    │
└──────────────┴────────────────────────┴────────────────────────┘
 Keys: 203/203 | Languages: 2                           [MODIFIED]

Features:

Side-by-side view of all languages
Real-time search and filtering
Add/edit/delete keys with full validation
Manage languages (add/remove with F2/F3)
Keyboard shortcuts for everything
Works perfectly over SSH
Menu bar for discoverability

It's everything I wanted from Visual Studio, but in the terminal. No GUI needed. No Windows needed. Just solid terminal tooling.

The Command-Line Experience

For scripting and automation, the CLI is comprehensive:

# Validate all .resx files
lrm validate

# Add a new key to both languages
lrm add WelcomeMessage \
  --lang default:"Welcome to our app" \
  --lang el:"Καλώς ήρθατε στην εφαρμογή μας"

# Update an existing key
lrm update SaveButton \
  --lang default:"Save Changes" \
  --lang el:"Αποθήκευση Αλλαγών"

# Delete a key from all languages
lrm delete OldFeature

# View a key across all languages
lrm view SaveButton
# Key: SaveButton
# English (Default): Save
# Ελληνικά (el): Αποθήκευση

# Export for translators (future-proofing)
lrm export -o translations.csv

# Import translated work
lrm import updated_translations.csv

# List all languages
lrm list-languages

# Add/remove languages
lrm add-language --culture fr
lrm remove-language --culture de

Every command is designed to work in scripts, CI/CD pipelines, or interactive use.

Future-Proofing: The Translator Workflow

While I'm currently doing all translations myself, I built LRM with the future in mind. When I eventually work with translators, the workflow is ready:

# Export current state to CSV
lrm export --include-status -o for_translator.csv

# Translator edits in Excel/Google Sheets
# (Much easier than editing XML!)

# Import completed translations
lrm import for_translator.csv --overwrite

# Validate everything imported correctly
lrm validate

# Check coverage
lrm stats

This is standard practice for professional localization workflows. LRM makes it trivial.

Why VS Code Extensions Aren't Enough

Someone might ask: "Why not just use VS Code with an extension?"

I tried. The available .resx extensions are mediocre at best:

Most just syntax highlight XML
No side-by-side language comparison
No validation
No batch operations
Still requires a GUI

More importantly: I work primarily in the terminal. SSH sessions, tmux, vim. Opening VS Code just to edit a translation breaks my flow entirely.

LRM fits naturally into a terminal-first workflow.

The Technical Stack

Built with modern .NET:

.NET 9 for cross-platform support
Spectre.Console.Cli for CLI framework
Terminal.Gui for interactive TUI
Self-contained binaries (no runtime needed)
Works on x64 and ARM64 (Raspberry Pi included)

Fully cross-platform:

Linux (x64, ARM64)
Windows (x64, ARM64)
Tested on GitHub Actions runners
Works in Docker containers

The architecture:

LocalizationManager/
├── Core/                   # Parsing, validation, models
├── Commands/               # CLI commands (validate, add, update, etc.)
├── UI/                     # Terminal.Gui TUI editor
└── Tests/                  # Comprehensive test suite

Everything is open source and well-documented.

Why This Matters for Linux .NET Developers

.NET on Linux is real. I'm building production WASM apps with .NET API backends, entirely on Linux. Many developers are doing the same.

But the tooling ecosystem still assumes Windows + Visual Studio for many tasks. Localization is just one example.

If you're:

Building .NET apps on Linux
Working primarily in the terminal
Using SSH for development
Running .NET in Docker/Kubernetes
Tired of "just use Visual Studio" answers

...you've probably hit these same walls.

LRM is proof that we can have first-class terminal tooling for .NET development on Linux. We don't need to compromise.

Open Source and Community-Driven

LRM is completely open source under the MIT license:

🔗 github.com/nickprotop/LocalizationManager

Quick start on Linux:

# One-line install
curl -sSL https://raw.githubusercontent.com/nickprotop/LocalizationManager/main/install-lrm.sh | bash

# Or download manually
wget https://github.com/nickprotop/LocalizationManager/releases/latest/download/lrm-linux-x64.tar.gz
tar -xzf lrm-linux-x64.tar.gz
sudo cp linux-x64/lrm /usr/local/bin/

# Start using it
cd YourProject/Resources
lrm validate
lrm edit

Documentation:

Try It Out

If you:

Develop .NET apps on Linux
Work primarily in the terminal
Need to manage localization
Want proper CLI tooling instead of GUI-only solutions

Give LRM a try. It's the tool I wished existed when I started building my WASM app.

Contributions, bug reports, and feature requests are welcome. This is a tool built to solve real problems for real developers working on Linux.

Links:

Do you develop .NET on Linux? What tooling gaps have you encountered? Let me know in the comments or open a discussion on GitHub. Let's make .NET on Linux a first-class experience.