DevLingo
A VS Code extension for translating selected text, code comments on hover, and Markdown files while preserving code and document structure. Currently in development with a mock translation provider.
Extension Developer
Project context
Developer-oriented translation workflows inside VS Code, built around an interchangeable provider and a shared translation service.
The problem
Translate developer documentation without corrupting code, links, or Markdown syntax, while keeping the translation engine interchangeable and source files safe.
Technical approach
Built a modular TypeScript extension with an injected translation service, a mock provider, comment detection, hover caching, and Markdown parsing based on source offsets. Translated Markdown is written atomically to a language-suffixed file, with confirmation before replacing existing output.
Design goal
Translate documentation within the editor while preserving the structure that makes it useful to developers. Selected text, comments, and Markdown have different interaction requirements, so they share a translation service without sharing the same source-processing workflow.
Translation architecture
The extension separates editor workflows from the translation engine through an injected translation service and an interchangeable provider. The current provider is a mock, making it possible to develop and test selection, hover, and Markdown workflows before connecting a real translation service. A bounded in-memory cache is shared by the translation workflows.
Provider abstraction
An injected translation service separates editor commands from the provider implementation. The current mock provider supports development of those workflows without claiming real translation quality. Replacing it with a real service should preserve the boundary between editor behavior and provider-specific communication.
Markdown source model
Markdown processing relies on source offsets to distinguish translatable text from protected document structure. Code, links, frontmatter, and HTML retain their role in the output. This is a document-preservation concern as much as a translation concern.
Protecting source documents
Selected text is translated without editing the source, and comment detection supports hover translation across twelve language IDs. Markdown translation uses source offsets to preserve code, links, frontmatter, and HTML. Output is written atomically to a language-suffixed file, with confirmation before an existing translation is replaced.
Selection and hover workflow
Selection translation leaves the source text unchanged. Comment detection enables hover translation across twelve language IDs, while caching avoids repeated work within the existing bounded in-memory cache. These interactions keep translation close to the document the developer is reading.
Atomic output and file safety
Translated Markdown is written to a language-suffixed output file rather than replacing the source document. Atomic creation protects the output-writing workflow, and confirmation is required before an existing translated file is replaced. These boundaries make the effects of the command explicit.
Key capabilities
- Translate selected text without editing the source
- Comment translation on hover across 12 language IDs
- Markdown translation preserving code, links, frontmatter, and HTML
- Configurable target language and bounded in-memory cache
- Atomic translated-file creation with overwrite confirmation
Outcome
Established three tested editor workflows with protected source files, Markdown-aware translation, and reusable translation caching.
Current state and next steps
DevLingo is in development and currently uses a mock translation provider. Its existing work establishes the editor workflows, document protection, and reusable service boundaries. Connecting a real provider will require decisions about credentials, network failures, provider limits, and translation quality before the extension can offer real-world translation.
Real-provider integration
The next provider introduces network requests, credentials, service limits, and translation-quality evaluation. Those concerns are outside the behavior of a mock provider. They need explicit handling before the extension can reliably translate real documents through an external service.
