If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/xupefei/Locale-Emulator shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 4y ago

• 19 active contributors
• LGPL-3.0 licensed
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 64% of recent commits
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live xupefei/Locale-Emulator repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/xupefei/Locale-Emulator.

What it runs against: a local clone of xupefei/Locale-Emulator — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in xupefei/Locale-Emulator | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1515 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of xupefei/Locale-Emulator. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/xupefei/Locale-Emulator.git
#   cd Locale-Emulator
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of xupefei/Locale-Emulator and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "xupefei/Locale-Emulator(\\.git)?\\b" \\
  && ok "origin remote is xupefei/Locale-Emulator" \\
  || miss "origin remote is not xupefei/Locale-Emulator (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1515 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1485d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/xupefei/Locale-Emulator"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Locale Emulator is a Windows system-level locale and region simulator that allows users to run applications with spoofed system locale settings without changing the actual OS locale. It intercepts system locale queries at runtime, enabling applications designed for specific regions (e.g., Japanese games) to run on systems with different default locales while preserving UI language and regional formatting. Three-project architecture: LECommonLibrary/ contains core config/profile reading and system helpers (LEConfig.cs, LEProfile.cs, PEFileReader.cs); LEContextMenuHandler/ is a COM-based Windows shell extension providing right-click context menu integration with 25+ language packs in Lang/; and LEGUI/ (inferred but not detailed in provided files) hosts the main WPF GUI. Locale profiles and associations are stored as serialized config files read by GlobalHelper and SystemHelper.

Gamers and software users who want to run region-locked or locale-specific applications (particularly Japanese games and software) on non-Japanese Windows systems without permanently changing system locale. Also useful for developers and QA engineers testing multi-locale application behavior.

Actively maintained and production-ready. The project has 3.4k+ total downloads across releases, a CI/AppVeyor setup, and is written in C# against .NET Framework standards. The codebase shows deliberate architecture (separate CommonLibrary, ContextMenuHandler, and GUI projects) and multi-language support (25+ language XML files for the UI). However, visibility is moderate for a niche utility.

Single-maintainer project (xupefei) with moderate risk. Requires building against an external dependency (Locale-Emulator-Core, a separate C++/native DLL library not in this repo) which must be cloned and built separately—this is a critical build step. The project relies on Windows-specific system hooks and PE file manipulation, making it fragile across Windows versions. No visible test suite in the file structure suggests limited automated coverage for locale hook scenarios.

No recent commit data is visible in the provided file list, so active development status is unclear. The presence of AppVeyor CI configuration and multiple language translations suggests periodic maintenance. The README instructs users to build against an external Locale-Emulator-Core repo, indicating the native hooking layer is under separate development.

1. Clone the repo: git clone https://github.com/xupefei/Locale-Emulator.git
2. Install Visual Studio 2015 or 2017 (solution uses .sln format)
3. Clone the core library separately: git clone https://github.com/xupefei/Locale-Emulator-Core and build it
4. Copy LoaderDll.dll and LocaleEmulator.dll from Locale-Emulator-Core build to this project's output folder
5. Open LocaleEmulator.sln in Visual Studio and Build (Ctrl+Shift+B)

Daily commands: Build in Visual Studio 2015+: File → Open Solution → LocaleEmulator.sln → Build → Build Solution (or press Ctrl+Shift+B). The compiled executables and DLLs will appear in bin/ folders. To use: run the GUI executable directly, or right-click an executable and select 'Locale Emulator' from the context menu (requires shell extension registration via ProjectInstaller.cs).

• LECommonLibrary/LEConfig.cs: Defines the profile data structure and serialization logic for storing locale emulation settings
• LECommonLibrary/GlobalHelper.cs: Central utility class providing access to locale profiles and configuration state across the application
• LECommonLibrary/PEFileReader.cs: Parses Windows PE (Portable Executable) file headers to detect application architecture and metadata—critical for the hooking mechanism to inject the correct DLL
• LEContextMenuHandler/FileContextMenuExt.cs: Implements the Windows shell context menu extension (COM integration) that enables right-click 'Run with Locale Emulator' functionality
• LEContextMenuHandler/Lang/DefaultLanguage.xml: Master language file for UI string definitions in the context menu handler; all other language XMLs inherit or override from this template
• LEContextMenuHandler/ProjectInstaller.cs: Handles Windows service/shell extension registration and installation—required to integrate the context menu handler into Windows Explorer

For UI strings/translations: edit LEGUI/Lang/DefaultLanguage.xaml or LEContextMenuHandler/Lang/DefaultLanguage.xml, then add language-specific XML files (e.g., ja.xml, zh-CN.xml). For locale profiles and config: modify LECommonLibrary/LEProfile.cs and LECommonLibrary/LEConfig.cs. For system integration: edit LEContextMenuHandler/FileContextMenuExt.cs for context menu behavior. For core hooking logic: changes require modifying the external Locale-Emulator-Core repo and rebuilding the native DLLs.

Critical external dependency: The build instructions mandate cloning and building xupefei/Locale-Emulator-Core separately, then manually copying LoaderDll.dll and LocaleEmulator.dll into the output directory—missing this step results in non-functional binaries. Shell extension registration: LEContextMenuHandler requires elevated privileges (admin) to register as a COM handler in the Windows registry (handled by ProjectInstaller.cs); development/testing requires running installer as admin. PE file architecture mismatch: PEFileReader must correctly identify 32-bit vs. 64-bit executables or the injected locale DLL will fail to load. Locale data format: LEProfile.cs uses custom serialization; modifying the profile format will break backward compatibility with existing saved profiles. No unit test framework visible: all testing is manual/integration-level.

• PE (Portable Executable) File Format — PEFileReader.cs parses PE headers to determine application bitness (32/64-bit) before injecting locale hooks; misdetecting this breaks the entire emulation
• Windows Shell Extension (COM) — LEContextMenuHandler implements COM interfaces to register a context menu handler in Windows Explorer; understanding COM registration and interface implementation is essential to modify shell integration
• DLL Injection / Process Hooking — The core mechanism: Locale Emulator injects LoaderDll and LocaleEmulator DLLs into target processes to intercept Windows API locale calls; the C# code coordinates this via PEFileReader and NativeMethods
• Windows Locale and Region APIs — The target of hooking: APIs like GetLocaleInfo, GetUserDefaultLCID, and SetLocale are intercepted; understanding what these do is critical to debugging locale emulation failures
• P/Invoke (Platform Invocation Services) — NativeMethods.cs uses P/Invoke to call Windows APIs from C# (e.g., registry operations, process management); developers modifying system integration need P/Invoke syntax
• Locale Profile Configuration Management — LEProfile.cs and LEConfig.cs handle persistence and loading of per-application locale settings; extending this requires understanding the custom serialization format

• xupefei/Locale-Emulator-Core — The native C++ DLL injection and locale hooking engine that this C# GUI wraps—required dependency for actual locale emulation
• torvalds/linux — Reference: the POSIX locale mechanism and environment variables that Locale Emulator mimics on Windows (different OS but same locale concept)
• AppImageCommunity/AppImageKit — Cross-platform analogue: AppImageKit provides application containerization and environment isolation on Linux, solving a related multi-locale/dependency problem
• Microsoft/Windows-classic-samples — Official Windows shell extension and context menu COM samples that Locale-Emulator's LEContextMenuHandler adapts (referenced in license)

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Complete missing language translations in LEGUI/Lang

The LEGUI/Lang directory has only 6 language files listed (ca, cs, de, es, fr, DefaultLanguage) but LEContextMenuHandler/Lang has 24 translation files including ja, ko, zh-CN, zh-TW, ru, pt-BR, etc. This inconsistency means the GUI lacks translations available in the context menu handler. A contributor should mirror all translations from LEContextMenuHandler/Lang to LEGUI/Lang to provide a consistent multilingual user experience.

• [ ] Audit all .xml files in LEContextMenuHandler/Lang/ (24 languages identified)
• [ ] Compare with LEGUI/Lang/.xaml files to identify missing languages
• [ ] Convert the 18+ missing language XMLs to XAML format matching DefaultLanguage.xaml structure
• [ ] Update LEGUI/App.xaml.cs I18n.cs to load the new language files
• [ ] Test GUI language switching with at least 5 newly added languages

Add unit tests for LECommonLibrary core utilities

LECommonLibrary contains critical functionality (GlobalHelper.cs, SystemHelper.cs, LEConfig.cs, LEProfile.cs, PEFileReader.cs) but there is no visible test project in the repository. These utilities handle system registry operations, PE file parsing, and configuration management which are error-prone and benefit greatly from test coverage. A new MSTest or xUnit project would improve code reliability and prevent regressions.

• [ ] Create new project LECommonLibrary.Tests with appropriate test framework
• [ ] Write unit tests for SystemHelper.cs registry/locale operations (minimum 10 test cases)
• [ ] Write unit tests for LEConfig.cs and LEProfile.cs configuration loading/saving (minimum 8 test cases)
• [ ] Write unit tests for PEFileReader.cs PE header parsing edge cases (minimum 6 test cases)
• [ ] Integrate tests into AppVeyor CI (update appveyor.yml if it exists)

Extract and document the Plugin/Hook API for LEContextMenuHandler

LEContextMenuHandler implements a shell extension (ShellExtLib.cs, NativeMethods.cs) with COM registration (ProjectInstaller.cs) but there is no API documentation. Other developers wanting to extend Locale Emulator or understand the system hooking mechanism have no reference guide. Creating a PLUGIN_API.md file with code examples would lower the barrier to contributions and advanced usage.

• [ ] Document the COM interface signatures in NativeMethods.cs with parameter descriptions
• [ ] Create PLUGIN_API.md explaining shell extension architecture and FileContextMenuExt.cs workflow
• [ ] Add code examples showing how to hook into file context menu operations
• [ ] Document the registry requirements for shell extension registration from ProjectInstaller.cs
• [ ] Include troubleshooting section for common COM registration issues on different Windows versions

• Add unit tests for LECommonLibrary/PEFileReader.cs—currently no test coverage visible for PE header parsing logic; create a test with sample 32-bit and 64-bit executable binaries to validate architecture detection
• Document the locale profile XML schema in README or a separate PROFILE_FORMAT.md file—LEProfile.cs loads profiles but there is no specification of the config file format, making it hard for contributors to extend profile features
• Expand language support: the LEContextMenuHandler/Lang folder has 25 languages but is missing major ones like ru.xml (Russian) and ar.xml (Arabic); contribute new language XML files following the DefaultLanguage.xml template structure

Locale Emulator is a Windows system utility with moderate security posture. Primary concerns include: (1) Strong Name Key files stored in version control, (2) P/Invoke usage without visible validation, (3) Registry and file operations requiring careful input validation, and (4) Shell extension running with system privileges. The codebase lacks visible evidence of injection vulnerabilities or major misconfigurations. No dependency file was provided for analysis. Recommendations focus on hardening native interop calls, securing cryptographic keys, implementing robust input validation, and following secure coding

• Medium · Potential Hardcoded Cryptographic Keys — LECommonLibrary/key.snk, LEContextMenuHandler/key.snk. Multiple .snk (Strong Name Key) files are present in the repository (LECommonLibrary/key.snk and LEContextMenuHandler/key.snk). While .snk files are necessary for .NET strong naming, storing them in version control can pose security risks if the repository becomes public or is compromised. The private key material could be exposed. Fix: Move .snk files to a secure key management system. Store keys in environment variables or secure vaults during build time. Add .snk files to .gitignore and use a CI/CD secret management system for code signing.
• Medium · P/Invoke Usage Without Validation — LEContextMenuHandler/NativeMethods.cs, LECommonLibrary/SystemHelper.cs. The codebase contains NativeMethods.cs which likely uses P/Invoke to call Windows APIs. P/Invoke calls can be a vector for security issues if not properly validated. Without examining the actual implementation, this is a potential risk area for buffer overflows, privilege escalation, or other low-level attacks. Fix: Review all P/Invoke declarations for proper parameter validation, bounds checking, and safe marshaling. Use SafeHandle for unmanaged resources. Validate all inputs before passing to native methods. Consider using Windows API Code Pack or other managed wrappers where available.
• Medium · Registry Access Without Validation — LECommonLibrary/LEConfig.cs, LECommonLibrary/LEProfile.cs, LECommonLibrary/AssociationReader.cs. The codebase appears to handle system configuration and profiles (LEConfig.cs, LEProfile.cs, AssociationReader.cs). These components likely interact with Windows Registry. Registry operations without proper validation can lead to security issues including privilege escalation or system compromise. Fix: Implement strict input validation for all registry keys and values. Use least privilege principles when accessing registry. Avoid user-controlled input in registry paths. Implement proper error handling and logging for registry operations.
• Low · Shell Extension Security Considerations — LEContextMenuHandler/FileContextMenuExt.cs, LEContextMenuHandler/ProjectInstaller.cs, LEContextMenuHandler/ShellExtLib.cs. LEContextMenuHandler registers as a shell extension which runs with elevated privileges in the context menu. Shell extensions are high-value targets for attacks as they execute in critical system processes. Fix: Ensure all code paths are thoroughly tested and reviewed. Implement code signing and certificate pinning. Use manifest declarations to request minimal required privileges. Implement robust error handling to prevent crashes that could be exploited.
• Low · XML Parsing Without DTD Protection — LEGUI/Lang/*.xaml, LEContextMenuHandler/Lang/*.xml, LEContextMenuHandler/Resource.resx, LECommonLibrary/Properties/Resources.resx. Multiple XML files are present (Lang configuration files, Resource files). If XML parsing is implemented without proper safeguards, it could be vulnerable to XXE (XML External Entity) attacks. Fix: Ensure XML parsing disables DTD processing and external entity resolution. Use XmlReaderSettings with appropriate security properties. When parsing XAML, use XamlReader with safe defaults. Validate XML schema against expected formats.
• Low · Potential File Path Traversal Risks — LECommonLibrary/AssociationReader.cs, LECommonLibrary/PEFileReader.cs. Components handling file associations (AssociationReader.cs) and PE file reading (PEFileReader.cs) may be vulnerable to path traversal attacks if file paths are not properly validated. Fix: Validate and normalize all file paths using Path.GetFullPath(). Use Path.Combine() safely. Implement whitelist validation for allowed directories. Avoid concatenating user input directly to file paths.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.