gtt: a terminal translator that swaps Google, DeepL, LibreTranslate and ChatGPT from one screen

What gtt actually solves for terminal users

Translation in a terminal usually means one of two things: piping text into a CLI that prints a single line, or alt-tabbing to a browser tab. gtt takes a third route. It is a full-screen TUI with a source pane and a destination pane, a pop out menu for settings, and a key map that covers translate, swap language, copy, and text to speech. The README describes it as a Google Translate TUI originally, and the supported backend list has since grown to Apertium, Bing, ChatGPT, DeepL, DeepLX, Google, LibreTranslate and Reverso.

The audience is narrow and specific. You write or read text in a terminal all day, you translate short passages rather than documents, and you care which engine handles the text. A developer reading a foreign-language issue thread, a technical writer checking terminology against two engines, or someone running a self-hosted LibreTranslate or DeepLX instance on localhost will get the most out of it. Anyone who needs a translation API to call from code, or who wants to translate a directory of files, is looking at the wrong tool.

Architecture: one TUI, eight backends behind a config file

The repository layout tells you most of the design. main.go, ui.go, key.go and config.go sit at the top level, with the backend work under internal/. The UI stack is tview on top of tcell, which is the standard pairing for Go terminal applications; tview supplies the panes and widgets, tcell handles the terminal. Configuration is read through Viper, and the README points at three YAML files under $XDG_CONFIG_HOME/gtt/ or $HOME/.config/gtt/: server.yaml for API keys and hosts, keymap.yaml for rebinding, and theme.yaml for colors.

The backend selection is the interesting part. Google is the default and needs no key. ChatGPT and DeepL require an API key, and the README notes DeepL support is limited to the free API. DeepLX and LibreTranslate are the two that can point at a server you host yourself, which is why server.yaml carries both an api_key block and a host block. Each key entry accepts either a literal value or a file path, so you can keep secrets out of the config file itself.

Text to speech is not an afterthought: go-mp3 and oto are direct dependencies, and that is why the README lists alsa-lib, libasound2-dev or alsa-lib-devel as system dependencies depending on your distribution. If you never use the TTS keys, you still pay for the audio library at build time.

Installing gtt and translating your first phrase

There are four documented install paths. On Arch, the AUR package is gtt-bin. Nix users can pull it from nixpkgs-unstable. Prebuilt binaries for Linux and macOS are on the release page. And because the module is a plain Go program, go install works if you have Go 1.25 or newer, which is what go.mod declares.

go install -ldflags="-s -w" github.com/eeeXun/gtt@latest

After that, make sure the Go binary directory is on your path, otherwise the shell will not find the command.

export PATH=$PATH:$HOME/go/bin

If you would rather not install anything, the project publishes a Docker image. The README gives this one-liner, and the -it flags matter because the TUI needs an interactive terminal.

docker run -it eeexun/gtt:latest

Once the program is running you get the two-pane layout. Type into the source pane, press Ctrl-j to translate, and the result appears in the destination pane. Ctrl-s swaps the languages, Ctrl-q clears the source pane. Pressing Escape opens the pop out menu, and number keys 1, 2 and 3 switch between its pages. You can also set the languages before launch, which is useful in a shell alias:

gtt -src "English" -dst "Chinese (Traditional)"

The README notes that valid language names depend on the backend, and points at each provider's own language list rather than maintaining one of its own.

Where the backend abstraction leaks

The README's language documentation is the clearest example of a limitation. Rather than listing supported languages, it defers to each provider: Apertium's own site, Bing's language-support page, Google's language list for both Google and ChatGPT, and so on for the rest. That is honest, but it means gtt cannot validate a language pair before you send a request. If you pass -src with a name the selected backend does not recognize, the failure surfaces as a translation error, not as a startup warning.

The ChatGPT backend deserves particular caution. It is an LLM behind a translation-shaped prompt, so the same input can produce different output on two runs, and the README does not document prompt handling, temperature, or any determinism guarantee. For terminology work where you need the same string translated the same way every time, that is a real problem. DeepL has the opposite constraint: only the free API is supported, so a paid DeepL plan does not buy you anything here.

Finally, the README does not document rollback or version pinning for the prebuilt binaries, and the jump from v10 in August 2024 to v11 in January 2026 is a long gap for anyone tracking releases. If you depend on a specific backend behaving a specific way, pin the version you installed.

How gtt compares with a script wrapping a translation API

The obvious alternative is to skip the TUI entirely and call a translation API from a shell function or a short script. That approach wins on automation: you can pipe a file through it, loop over a list of strings, or wire it into a build step. gtt cannot do any of that. It is an interactive program with a fixed screen, and its output goes to the destination pane, not to stdout.

What gtt gives you instead is comparison. Switching from Google to DeepL to Reverso is a menu action, not a rewrite of your script's HTTP call, and each backend's quirks are handled by the same binary. It also handles the parts a shell script usually skips: text to speech for the source and destination panes, clipboard integration through xclip or wl-clipboard, and OSC 52 support for terminals that can copy without either helper. If your actual workflow is "paste a sentence, look at two engines, copy the better one," the TUI is doing more work than a wrapper would.

Maintenance, licence and upgrade cost

gtt is MIT licensed, which is permissive: you can use, modify and redistribute it, including in commercial settings, provided the licence text and copyright notice travel with it. That is a summary of the licence identifier in the repository, not legal advice; read the LICENSE file if the distinction matters to your organization.

The repository is not archived, and the last push was on 2026-08-02, so the codebase is being touched. Release cadence is another matter. v11 landed on 2026-01-24, after v10 on 2024-08-10 and v9 on 2024-02-11. That is roughly one release every six to eighteen months. For a personal tool this is fine. For a team standardizing on gtt, it means backend breakage (a provider changing an endpoint, a free tier closing) may sit unfixed for months, and you should be prepared to patch internal/ yourself.

Upgrade cost is low in normal cases because configuration lives outside the binary in server.yaml, keymap.yaml and theme.yaml. The exception is keymap.yaml: if you have rebound keys, check the example file after a major version, since the README's key map section is the only reference for the valid action names.

Configuring API keys and self-hosted endpoints

Everything provider-specific lives in one file. The README's example shows the shape: an api_key map keyed by backend name, where each entry takes either a value or a file path, plus a separate host map for the self-hosted providers.

api_key:
  chatgpt:
    value: CHATGPT_API_KEY
    # file: $HOME/secrets/chatgpt.txt
  deepl:
    value: DEEPL_API_KEY
host:
  deeplx: 127.0.0.1:1188
  libre: 127.0.0.1:5000

Note that DeepLX and LibreTranslate each need both an entry and, for DeepLX, an optional token depending on how you configured the server. The README states the DeepLX API key is optional. If you point host at the wrong port, the symptom is a failed translation rather than a config error at startup, so test each backend once after editing this file.

Copying text out of the TUI has its own setup. On Linux/X11 you want xclip, on Wayland wl-clipboard, and if neither is installed you can enable OSC 52 from page 2 of the pop out menu, provided your terminal supports it. The README treats both helpers as optional, which is accurate only if your terminal speaks OSC 52.

Editorial conclusion

Adopt gtt if you translate short passages all day and want to switch backends without leaving the terminal; skip it if you need a documented translation API, batch file translation, or a backend matrix that stays correct without you reading the source. Before committing, verify that your chosen backend still answers with the current release, check whether your terminal needs xclip, wl-clipboard or OSC 52 for copying, and read example/server.yaml to see exactly which keys and hosts each provider expects.

Frequently asked questions

Official sources

1. eeeXun/gtt on GitHub
2. Issues
3. License: MIT
4. README
5. Releases