Prompt to convert code to another language

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You are fluent in both {{from_language}} and {{to_language}}, and you write idiomatic {{to_language}} rather than transliterated {{from_language}}.

<context>
<source_code language="{{from_language}}">
{{code}}
</source_code>
</context>

<constraints>
- Use {{to_language}} idioms, standard library and error handling conventions, not a line-by-line copy.
- Target environment: {{target}}. Use only libraries available there; name any dependency you add.
- Keep behaviour the same, including edge cases: integer division, string encoding, null handling, sorting stability, time zones.
- Where the languages genuinely differ and identical behaviour isn’t possible or sensible, choose the idiomatic option and list the difference.
</constraints>

<output_format>
1. The converted code in one block.
2. A table of library mappings (source → target).
3. A list headed “Behaviour differences”, one line each, or “None found”.
</output_format>

<task>
Convert this code to {{to_language}}. The result should behave the same and read as if a {{to_language}} developer wrote it.
</task>

You are fluent in both {{from_language}} and {{to_language}}, and you write idiomatic {{to_language}} rather than transliterated {{from_language}}.

<constraints>
- Use {{to_language}} idioms, standard library and error handling conventions, not a line-by-line copy.
- Target environment: {{target}}. Use only libraries available there; name any dependency you add.
- Keep behaviour the same, including edge cases: integer division, string encoding, null handling, sorting stability, time zones.
- Where the languages genuinely differ and identical behaviour isn’t possible or sensible, choose the idiomatic option and list the difference.
</constraints>

<output_format>
1. The converted code in one block.
2. A table of library mappings (source → target).
3. A list headed “Behaviour differences”, one line each, or “None found”.
</output_format>

<context>
<source_code language="{{from_language}}">
{{code}}
</source_code>
</context>

<task>
Convert this code to {{to_language}}. The result should behave the same and read as if a {{to_language}} developer wrote it.
</task>

{{from_language}}

The source language, such as Python.

{{to_language}}

The target language, such as TypeScript.

{{code}}

The code to convert. Smaller units convert better than whole programs.

{{target}}

Where the result will run, such as “Node.js 22, ESM, no new npm packages” or “Go 1.24 standard library only”.

{{from_language}}

Python

{{to_language}}

TypeScript

{{code}}

def bucket(values: list[int], size: int) -> dict[int, list[int]]:
    out: dict[int, list[int]] = {}
    for v in sorted(values):
        out.setdefault(v // size, []).append(v)
    return out

{{target}}

Node.js 22, ESM, strict TypeScript, no new npm packages

What to look for. Two traps here: sorted must become a numeric sort ((a, b) => a - b), and Python’s floor division needs Math.floor(v / size), which differs from truncation for negative numbers. A good answer handles both and mentions them under behaviour differences.

You are fluent in both Python and TypeScript, and you write idiomatic TypeScript rather than transliterated Python.

<context>
<source_code language="Python">
def bucket(values: list[int], size: int) -> dict[int, list[int]]:
    out: dict[int, list[int]] = {}
    for v in sorted(values):
        out.setdefault(v // size, []).append(v)
    return out
</source_code>
</context>

<constraints>
- Use TypeScript idioms, standard library and error handling conventions, not a line-by-line copy.
- Target environment: Node.js 22, ESM, strict TypeScript, no new npm packages. Use only libraries available there; name any dependency you add.
- Keep behaviour the same, including edge cases: integer division, string encoding, null handling, sorting stability, time zones.
- Where the languages genuinely differ and identical behaviour isn’t possible or sensible, choose the idiomatic option and list the difference.
</constraints>

<output_format>
1. The converted code in one block.
2. A table of library mappings (source → target).
3. A list headed “Behaviour differences”, one line each, or “None found”.
</output_format>

<task>
Convert this code to TypeScript. The result should behave the same and read as if a TypeScript developer wrote it.
</task>

• All models

  Convert the tests too, separately and first. Running the original tests against the new code is the fastest way to find semantic differences the model didn’t mention.

• Gemini

  Google recommends few-shot examples for Gemini. If you convert many files in one codebase, include one already-converted pair as an example so naming and error-handling choices stay consistent.

• Claude

  Anthropic suggests XML tags for mixed content. Keep the language attribute on the source tag when you paste several files, so each one is clearly labelled.

• Refactor codeRestructure code toward one stated goal without changing behaviour, with risky steps flagged.
• Write unit testsTests for normal cases, edge cases and errors in your framework, focused on behaviour rather than implementation.
• Explain codeA plain-English walkthrough of unfamiliar code at the reader’s level: purpose, flow, side effects and traps.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.