Code Viewer with Real-Time Translation

A VS Code extension that lets developers view source code in their own language without modifying the original files.

Overview

Programming languages are mostly built around English keywords, APIs, function names, and naming conventions.

For people who are learning programming but do not speak English, this creates an additional barrier: before understanding the logic of a program, they must first understand the language used to describe it.

Code Viewer with Real-Time Translation aims to remove that barrier.

The extension will add a translated view of the source code directly inside VS Code. The developer will be able to click an eye icon, choose a language, and see the code translated in real time.

The original source code will remain untouched.

for user in active_users:
    if user.has_permission:
        send_notification(user)

Could be displayed in Portuguese as:

para usuario em usuarios_ativos:
    se usuario.tem_permissao:
        enviar_notificacao(usuario)

The translated version is only a visual representation. The file saved on disk, executed by the interpreter, committed to Git, and shared with other developers remains the original source code.

Core Principle

This project does not send complete source files to a translation service.

Instead, it:

Parses the source code.
Identifies tokens and symbols.
Classifies each item.
Translates only eligible words.
Rebuilds a translated visual representation.
Preserves the original structure and formatting as much as possible.

The extension must understand the difference between:

Language keywords
Variables
Functions
Methods
Classes
Parameters
Properties
Imports
Strings
Comments
Operators
Punctuation
Library APIs
User-created symbols

This prevents the translation process from breaking the code structure or translating text that should remain unchanged.

Goals

Make real source code easier to understand for people who do not speak English.
Provide a translated view without modifying the original file.
Support multiple programming languages.
Support multiple human languages.
Translate progressively, without waiting for the entire file.
Cache translations so repeated words appear immediately.
Preserve naming conventions such as camelCase, PascalCase, snake_case, and SCREAMING_SNAKE_CASE.
Avoid sending private source code to external services.
Allow local translation models.
Build a community-maintained translation database.
Help beginners gradually learn the original English terminology.

Non-Goals

This project is not intended to:

Create a new programming language.
Replace Python, JavaScript, Kotlin, Swift, or any other language.
Modify source files automatically.
Translate an entire source file as plain text.
Generate code using translated keywords and execute it directly.
Replace language servers, compilers, or interpreters.
Guarantee that every identifier has a single universal translation.

The project is a localized visual layer over real source code.

Initial Language Support

The first implementation will focus on:

Python
JavaScript
TypeScript
PHP
Swift
Kotlin
Java

Python will be the first supported language because:

It is widely used in education.
Its syntax is relatively approachable.
It has a strong standard library.
It is commonly used by beginners.
Its AST and tokenization tools are mature.

Each programming language will require its own parser adapter.

User Experience

The extension should add an eye icon to the VS Code editor toolbar.

When translation is disabled:

👁 Original

When translation is enabled:

👁 Portuguese

The user should be able to:

Enable or disable the translated view.
Choose the target language.
Switch between original and translated code instantly.
See translations appear progressively.
Hover over a translated symbol to see the original name.
Click a translated symbol to inspect its source.
Lock or customize a translation.
choose between translated, bilingual, and original modes.

Possible visualization modes:

Original

if current_user.has_permission:
    return load_profile(current_user)

Translated

se usuario_atual.tem_permissao:
    retornar carregar_perfil(usuario_atual)

Bilingual

se [if] usuario_atual [current_user].tem_permissao [has_permission]:
    retornar [return] carregar_perfil [load_profile](usuario_atual [current_user])

The bilingual mode may be especially useful for education because it reduces the initial language barrier without hiding the terminology used by the programming ecosystem.

Translation Pipeline

Source File
    ↓
Language Detection
    ↓
Parser / Tokenizer
    ↓
Token and Symbol Classification
    ↓
Translation Eligibility Rules
    ↓
Translation Cache
    ↓
Local Dictionary
    ↓
Community Dictionary
    ↓
Local Translation Model or External Provider
    ↓
Naming Convention Reconstruction
    ↓
Translated Visual Document

The extension must never treat source code as ordinary prose.

Token Classification

Each language adapter must produce a normalized representation of the source code.

Example:

interface CodeToken {
  text: string;
  type:
    | "keyword"
    | "variable"
    | "function"
    | "method"
    | "class"
    | "parameter"
    | "property"
    | "import"
    | "string"
    | "comment"
    | "operator"
    | "punctuation"
    | "unknown";
  start: number;
  end: number;
  line: number;
  column: number;
  symbolId?: string;
  semanticType?: string;
  translatable: boolean;
}

A parser adapter should identify not only the textual token, but also its semantic role.

For example:

replace = "value"
text.replace("a", "b")

The first replace is a user-created variable.

The second replace may be a known method from the Python standard library.

They cannot be translated using the same rule.

Language Adapters

Each programming language will have an isolated adapter.

interface LanguageAdapter {
  id: string;
  extensions: string[];

  parse(source: string): Promise<ParsedDocument>;

  classifyTokens(
    document: ParsedDocument
  ): Promise<CodeToken[]>;

  resolveSymbols(
    document: ParsedDocument
  ): Promise<ResolvedSymbol[]>;

  getKnownKeywords(): ReadonlySet<string>;

  getStandardLibrarySymbols(): Promise<LibrarySymbol[]>;
}

Possible parser technologies:

Language	Initial parser option
Python	Python `tokenize`, `ast`, Tree-sitter, or Pyright
JavaScript	TypeScript Compiler API or Tree-sitter
TypeScript	TypeScript Compiler API
PHP	PHP Parser or Tree-sitter
Swift	SwiftSyntax or SourceKit-LSP
Kotlin	Kotlin PSI, Kotlin Language Server, or Tree-sitter
Java	JavaParser, Eclipse JDT, or Tree-sitter

The architecture should allow parser implementations to be replaced without changing the translation engine.

Tree-sitter may be useful as a shared parsing layer, but language servers and native parser APIs may provide better semantic information.

Translation Eligibility

Not every token should be translated.

Usually translated

Programming language keywords
User-created variable names
User-created function names
User-created class names
User-created parameters
Known standard-library APIs
Known framework APIs
Comments, when explicitly enabled

Usually preserved

Operators
Punctuation
Numeric literals
File paths
URLs
Hashes
Encoded values
Package identifiers
Import paths, unless safely mapped
String literals, unless explicitly enabled
Public API names when changing them would create ambiguity
Symbols marked as non-translatable

Translation rules must be configurable per language and per workspace.

Keyword Translation

Language keywords are deterministic and should not require AI.

Example dictionary:

{
  "language": "python",
  "locale": "pt-BR",
  "keywords": {
    "if": "se",
    "else": "senão",
    "elif": "senão_se",
    "for": "para",
    "while": "enquanto",
    "return": "retornar",
    "class": "classe",
    "def": "definir",
    "import": "importar",
    "from": "de",
    "as": "como",
    "try": "tentar",
    "except": "exceto",
    "finally": "finalmente",
    "with": "com",
    "yield": "produzir",
    "await": "aguardar",
    "async": "assíncrono"
  }
}

Keyword translations should be reviewed and versioned because readability may be more important than literal translation.

Symbol Translation

User-created symbols require more context.

Example:

active_users
currentUser
HTTPResponse
sendNotification

Possible translations:

active_users      → usuarios_ativos
currentUser       → usuarioAtual
HTTPResponse      → RespostaHTTP
sendNotification  → enviarNotificacao

The translation engine should:

Detect the naming convention.
Split the identifier into semantic words.
Translate each word.
Rebuild the identifier using the original convention.

Naming Convention Preservation

Supported conventions should include:

camelCase
PascalCase
snake_case
SCREAMING_SNAKE_CASE
kebab-case
dot.case
Mixed identifiers containing acronyms
Numeric suffixes and prefixes

Examples:

Original	Portuguese
`currentUser`	`usuarioAtual`
`CurrentUser`	`UsuarioAtual`
`current_user`	`usuario_atual`
`CURRENT_USER`	`USUARIO_ATUAL`
`current-user`	`usuario-atual`
`HTTPResponse`	`RespostaHTTP`
`user2FAStatus`	`status2FAUsuario`

The exact behavior for acronyms and mixed identifiers must be configurable and covered by tests.

Translation Providers

The translation engine should support interchangeable providers.

interface TranslationProvider {
  id: string;

  isAvailable(): Promise<boolean>;

  translate(request: TranslationRequest): Promise<TranslationResult>;
}

Possible providers:

Built-in dictionaries
Workspace dictionaries
Community dictionaries
Local translation models
Google Cloud Translation
DeepL
Microsoft Translator
OpenAI-compatible local endpoints
Custom providers added by extensions

The system should prioritize privacy-preserving providers.

Recommended priority:

Workspace Override
    ↓
Local Cache
    ↓
Built-in Dictionary
    ↓
Community Dictionary
    ↓
Local Translation Model
    ↓
External Translation API
    ↓
Keep Original

Privacy Model

Privacy is a core requirement.

The extension should never send complete files or complete code blocks to a translation provider by default.

External requests should contain only the smallest possible translation unit.

Example:

{
  "sourceLanguage": "en",
  "targetLanguage": "pt-BR",
  "words": [
    "current",
    "user",
    "permission"
  ]
}

The extension should avoid sending:

Full files
Complete functions
Business logic
String literals
Comments containing sensitive information
Repository names
File paths
Surrounding code
API keys
Credentials
Customer information

A strict privacy mode should disable all external providers and use only:

Built-in dictionaries
Local cache
Workspace dictionaries
Local translation models

Users must be able to inspect exactly which values would be sent before enabling an external provider.

Local Translation Models

Translation models can be significantly smaller than general-purpose LLMs.

The project should support lightweight local models through an abstraction layer.

Possible local runtimes may include:

ONNX Runtime
Transformers.js
llama.cpp-compatible translation models
Local HTTP services
Native platform inference
Dedicated machine-translation models

The extension should not depend on a large language model for its core functionality.

Deterministic dictionaries and lightweight translation models should cover most use cases.

Cache Strategy

Translations should be cached aggressively.

The first time a word or symbol is translated, the result should be stored locally.

Future uses of the same translation should be nearly instantaneous.

A translation cache key should include enough context to avoid incorrect collisions.

interface TranslationCacheKey {
  sourceLocale: string;
  targetLocale: string;
  programmingLanguage: string;
  tokenType: string;
  semanticType?: string;
  normalizedValue: string;
  namingConvention?: string;
  providerVersion?: string;
}

Example:

pt-BR:python:keyword:return
pt-BR:python:function:load_profile:snake_case
pt-BR:typescript:method:Array.prototype.forEach
pt-BR:kotlin:class:UserRepository:PascalCase

The cache should have multiple layers:

Memory cache
Workspace cache
User cache
Built-in cache
Community cache

Possible storage:

.vscode/code-translator.json
.code-translator/translations.pt-BR.json
VS Code globalState
SQLite
IndexedDB

Workspace translations should be shareable through Git when the team chooses to commit them.

Incremental Translation

The extension should not wait for the entire file to be translated before showing results.

Translation should happen progressively.

Suggested priority:

Visible lines
Current cursor line
Current function or scope
Remaining lines in the viewport
Rest of the file
Related open files
Remaining workspace symbols

Example:

Line 1 translated
Line 2 translated
Line 3 translated
...

The translated view should update as results become available.

This makes the experience feel immediate even when some words require a translation provider.

The extension should cancel outdated translation jobs when:

The document changes
The user changes the target language
The editor closes
The translation mode is disabled
A newer translation request supersedes the previous one

Line and Token Cache

In addition to word-level translation caching, the extension may keep a rendered line cache.

interface RenderedLineCache {
  documentUri: string;
  documentVersion: number;
  targetLocale: string;
  lineNumber: number;
  sourceHash: string;
  translatedText: string;
  tokenMappings: TokenMapping[];
}

A line should only be regenerated when:

Its source content changes
One of its translations changes
The target language changes
Translation settings change
The parser version changes

The source hash prevents stale translated lines from being displayed.

Visual Document Architecture

The original file must remain unchanged.

For the first version, the safest implementation is a translated virtual document or custom editor view.

Original File
    ↕ synchronized
Translated Virtual Document

The translated document should:

Be read-only initially
Preserve line mappings
Synchronize scrolling
Synchronize cursor position
Support hover mappings
Show original symbols on demand
Update when the original file changes
Render progressively

A command may initially open the translated view:

Code Translator: Open Translated View

A later version may add a toolbar eye icon:

$(eye) Show Translated Code
$(eye-closed) Show Original Code

Replacing text visually inside the standard VS Code editor without changing the underlying document may be limited by the public VS Code API.

For that reason, the project should begin with a virtual document or custom editor architecture and evaluate more advanced rendering later.

VS Code Extension Architecture

Suggested modules:

src/
├── extension.ts
├── commands/
│   ├── openTranslatedView.ts
│   ├── toggleTranslation.ts
│   ├── changeTargetLanguage.ts
│   └── clearTranslationCache.ts
├── editor/
│   ├── translatedDocumentProvider.ts
│   ├── translatedEditorController.ts
│   ├── cursorSynchronizer.ts
│   ├── scrollSynchronizer.ts
│   └── tokenHoverProvider.ts
├── languages/
│   ├── languageAdapter.ts
│   ├── registry.ts
│   └── python/
│       ├── pythonAdapter.ts
│       ├── pythonTokenizer.ts
│       ├── pythonAstResolver.ts
│       └── pythonKeywords.ts
├── translation/
│   ├── translationEngine.ts
│   ├── translationProvider.ts
│   ├── translationQueue.ts
│   ├── identifierSplitter.ts
│   ├── namingConvention.ts
│   └── providers/
│       ├── builtInDictionaryProvider.ts
│       ├── workspaceDictionaryProvider.ts
│       ├── localModelProvider.ts
│       └── externalApiProvider.ts
├── cache/
│   ├── memoryCache.ts
│   ├── workspaceCache.ts
│   ├── globalCache.ts
│   └── renderedLineCache.ts
├── rendering/
│   ├── translatedRenderer.ts
│   ├── lineRenderer.ts
│   └── tokenMapping.ts
├── privacy/
│   ├── privacyPolicy.ts
│   ├── requestSanitizer.ts
│   └── externalProviderConsent.ts
└── community/
    ├── dictionaryLoader.ts
    ├── dictionaryValidator.ts
    └── dictionaryExporter.ts

Suggested Core Types

interface ParsedDocument {
  uri: string;
  languageId: string;
  version: number;
  source: string;
  tokens: CodeToken[];
  symbols: ResolvedSymbol[];
}

interface ResolvedSymbol {
  id: string;
  name: string;
  kind:
    | "variable"
    | "function"
    | "method"
    | "class"
    | "parameter"
    | "property"
    | "module";
  declarationRange?: SourceRange;
  references: SourceRange[];
  semanticOwner?: string;
}

interface TranslationRequest {
  sourceLocale: string;
  targetLocale: string;
  programmingLanguage: string;
  originalText: string;
  words: string[];
  tokenType: CodeToken["type"];
  semanticType?: string;
  namingConvention?: NamingConvention;
}

interface TranslationResult {
  translatedText: string;
  provider: string;
  confidence?: number;
  alternatives?: string[];
  cached: boolean;
}

interface TokenMapping {
  originalRange: SourceRange;
  translatedRange: SourceRange;
  originalText: string;
  translatedText: string;
  symbolId?: string;
}

Python MVP

The first milestone will support Python files.

The Python adapter should identify:

Keywords
Identifiers
Function declarations
Class declarations
Parameters
Variable assignments
Attribute access
Imports
Calls
Comments
Strings
Operators
Indentation
Scope
Symbol references

Possible implementation options:

Option A: Native Python helper process

The extension runs a small Python process using:

tokenize
ast
symtable

Advantages:

Uses the official Python parser.
Provides reliable syntax information.
Easy to prototype.

Disadvantages:

Requires Python to be installed.
Requires process communication.
Packaging is more complex.

Option B: Tree-sitter Python

Advantages:

Runs inside the extension.
Fast incremental parsing.
Does not require a Python installation.
Easier cross-platform packaging.

Disadvantages:

Semantic symbol resolution is more limited.
Additional analysis is needed for references and types.

Option C: Pyright integration

Advantages:

Strong semantic analysis.
Symbol and type information.
Already designed for editor tooling.

Disadvantages:

More complex integration.
May depend on internal or indirect APIs.
Heavier than a simple tokenizer.

A practical MVP may begin with Tree-sitter or a native Python helper, while keeping the adapter interface independent from the parser implementation.

Python MVP Translation Example

Original:

def find_active_users(users):
    active_users = []

    for user in users:
        if user.is_active:
            active_users.append(user)

    return active_users

Translated view:

definir encontrar_usuarios_ativos(usuarios):
    usuarios_ativos = []

    para usuario em usuarios:
        se usuario.esta_ativo:
            usuarios_ativos.adicionar(usuario)

    retornar usuarios_ativos

Possible bilingual view:

definir [def] encontrar_usuarios_ativos [find_active_users](usuarios [users]):
    usuarios_ativos [active_users] = []

    para [for] usuario [user] em [in] usuarios [users]:
        se [if] usuario [user].esta_ativo [is_active]:
            usuarios_ativos [active_users].adicionar [append](usuario [user])

    retornar [return] usuarios_ativos [active_users]

Community Dictionaries

Translations should be shareable.

Suggested repository structure:

dictionaries/
├── pt-BR/
│   ├── python/
│   │   ├── keywords.json
│   │   ├── builtins.json
│   │   └── standard-library.json
│   ├── javascript/
│   ├── typescript/
│   ├── php/
│   ├── swift/
│   ├── kotlin/
│   └── java/
├── es/
├── fr/
├── de/
└── ja/

Example entry:

{
  "symbol": "list.append",
  "sourceLanguage": "en",
  "targetLanguage": "pt-BR",
  "translation": "adicionar",
  "alternatives": [
    "acrescentar",
    "inserir"
  ],
  "status": "approved",
  "context": "python.builtin.list"
}

Community translations should support:

Review status
Alternatives
Context
Programming language
Library or framework
Version
Contributors
Validation
Conflict resolution

Workspace Overrides

A project should be able to define preferred translations.

{
  "locale": "pt-BR",
  "translations": {
    "symbols": {
      "src/auth.py#current_user": "usuario_atual",
      "src/auth.py#has_permission": "tem_permissao"
    },
    "terms": {
      "repository": "repositorio",
      "gateway": "gateway"
    }
  }
}

This allows teams and teachers to keep terminology consistent.

Configuration

Possible VS Code settings:

{
  "codeTranslator.enabled": true,
  "codeTranslator.targetLanguage": "pt-BR",
  "codeTranslator.mode": "translated",
  "codeTranslator.translateKeywords": true,
  "codeTranslator.translateIdentifiers": true,
  "codeTranslator.translateKnownApis": true,
  "codeTranslator.translateComments": false,
  "codeTranslator.translateStrings": false,
  "codeTranslator.externalProviders.enabled": false,
  "codeTranslator.localModel.enabled": true,
  "codeTranslator.cache.workspace": true,
  "codeTranslator.cache.global": true,
  "codeTranslator.privacy.strictMode": true
}

Performance Requirements

The extension should:

Prioritize visible code.
Avoid reparsing unchanged documents.
Use incremental parsing when possible.
Cache tokenization results.
Cache translations.
Cache rendered lines.
Cancel stale jobs.
Batch translation requests by isolated words.
Avoid blocking the VS Code extension host.
Perform expensive work in worker threads or child processes.
Render partial results immediately.
Keep original-to-translated mappings stable.

Target behavior:

Cached files should open translated almost instantly.
Visible lines should be prioritized.
Translation should continue in the background while the user reads.
Typing in the original document should update only affected regions.

Security Requirements

Never execute translated content.
Never modify source files without explicit user action.
Never send full code to external providers by default.
Sanitize external translation requests.
Do not translate secrets or encoded values.
Respect VS Code Workspace Trust.
Support offline-only mode.
Make telemetry opt-in.
Never include source code in telemetry.
Validate downloaded community dictionaries.
Sign or checksum dictionary releases when possible.

Accessibility and Education

This project is not only a translation tool.

It can also become a bridge between local-language learning and real-world programming terminology.

Potential educational features:

Bilingual token display
Original-term hover
Translation explanations
Vocabulary history
“Learn this word” mode
Beginner and advanced translation profiles
Teacher-controlled dictionaries
Classroom workspace dictionaries
Gradual reduction of translations over time

Example learning mode:

se [if]
retornar [return]
para cada [for each]
usuario atual [current user]

The user can progressively move from fully translated code to the original language.

Roadmap

Phase 0 — Repository and Architecture

Phase 1 — Python Proof of Concept

Phase 2 — Python Semantic Translation

Resolve variables, functions, classes, and parameters
Translate user-created identifiers
Preserve naming conventions
Recognize Python built-ins
Recognize standard-library APIs
Add workspace translation overrides
Add global persistent cache
Add progressive viewport-first translation
Add hover with original symbol

Phase 3 — Translation Providers

Add provider abstraction
Add lightweight local model support
Add optional external translation providers
Add strict privacy mode
Add provider consent UI
Add translation review and correction
Add provider confidence metadata

Phase 4 — Educational Modes

Phase 5 — JavaScript and TypeScript

Add TypeScript Compiler API adapter
Translate JavaScript keywords
Translate TypeScript keywords
Resolve symbols and references
Recognize standard APIs
Recognize common framework APIs

Phase 6 — Additional Languages

Phase 7 — Community Translation Platform

Publish dictionary format
Add validation tooling
Add translation contribution workflow
Add review and approval system
Add dictionary versioning
Add automatic dictionary updates

Open Architectural Questions

Should the first Python parser use Tree-sitter or a native Python helper?
Can the translated view provide a good enough experience using virtual documents?
Should translated views be editable in the future?
How should symbol context be represented across languages?
How should ambiguous translations be reviewed?
How should acronyms be preserved?
Should comments be translated by default?
How should framework-specific dictionaries be distributed?
How should community dictionaries be signed and validated?
How should the extension behave when a translated identifier becomes longer than the original?
How should debugging and breakpoints map to translated views?
Can semantic tokens from language servers be reused safely?
Should the community cache be centralized or distributed through Git repositories?

Proposed Technical Stack

Initial suggestion:

TypeScript
VS Code Extension API
Tree-sitter or native parser adapters
Worker threads or child processes
SQLite or structured JSON for persistent cache
Vitest
ESLint
Prettier
GitHub Actions

The project should avoid coupling the core translation engine to VS Code so it may later be reused by:

Other editors
Web-based code viewers
Educational platforms
Documentation tools
IDE plugins
CLI tools

Suggested package separation:

packages/
├── core/
├── vscode-extension/
├── parser-python/
├── parser-typescript/
├── translation-local/
├── translation-external/
├── dictionaries/
└── test-fixtures/

Possible Project Names

Current working title:

Code Viewer with Real-Time Translation

Possible shorter names:

CodeLingo
Localized Code
NativeCode View
Polyglot Code View
Code Translator View
LingoCode
Code in My Language

The repository name can remain technical while the extension uses a shorter product name.

Example:

Repository: code-viewer-real-time-translation
Extension: CodeLingo

Contributing

This project is in its earliest architectural stage.

Contributions will be needed in:

VS Code extension development
Compiler and parser integration
Python tooling
JavaScript and TypeScript tooling
Translation models
Localization
UX and accessibility
Security and privacy
Education
Dictionary review
Documentation

Before implementing a new language adapter, contributors should follow the common parser and token classification interfaces.

Every translation feature must preserve the original source file and respect the privacy model.

License

A permissive open-source license such as MIT or Apache-2.0 is recommended.

The final license has not yet been selected.

Status

Early concept and architecture design.

The first planned implementation is a Python proof of concept for VS Code with Portuguese translation support.

Vision

Programming should not require fluency in English before a person can understand logic, variables, conditions, loops, functions, and algorithms.

Code Viewer with Real-Time Translation aims to let people learn programming through real code while gradually becoming familiar with the terminology used by the global developer community.

The source code stays real.

The execution stays real.

The tools stay real.

Only the way the code is presented changes.

Name		Name	Last commit message	Last commit date
README.md		README.md

Latest commit

History

Folders and files

Repository files navigation

Code Viewer with Real-Time Translation

Overview

Core Principle

Goals

Non-Goals

Initial Language Support

User Experience

Original

Translated

Bilingual

Translation Pipeline

Token Classification

Language Adapters

Translation Eligibility

Usually translated

Usually preserved

Keyword Translation

Symbol Translation

Naming Convention Preservation

Translation Providers

Privacy Model

Local Translation Models

Cache Strategy

Incremental Translation

Line and Token Cache

Visual Document Architecture

VS Code Extension Architecture

Suggested Core Types

Python MVP

Option A: Native Python helper process

Option B: Tree-sitter Python

Option C: Pyright integration

Python MVP Translation Example

Community Dictionaries

Workspace Overrides

Configuration

Performance Requirements

Security Requirements

Accessibility and Education

Roadmap

Phase 0 — Repository and Architecture

Phase 1 — Python Proof of Concept

Phase 2 — Python Semantic Translation

Phase 3 — Translation Providers

Phase 4 — Educational Modes

Phase 5 — JavaScript and TypeScript

Phase 6 — Additional Languages

Phase 7 — Community Translation Platform

Open Architectural Questions

Proposed Technical Stack

Possible Project Names

Code Viewer with Real-Time Translation

Contributing

License

Status

Vision

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors