Dialect is a GNOME translation client that keeps your provider choice in one place

A desktop shell around translation services you already have access to

Dialect describes itself in three words: a translation app for GNOME. That framing matters, because Dialect is not a translation engine. It is a client, written in Python with a GTK4 and libadwaita interface, that sends your text to a provider you choose and shows you the result.

The provider list is the substance of the project. The proprietary options are Google Translate, DeepL, Kagi Translate, Microsoft Translator (Bing) and Yandex Translate. Two of them need credentials you supply: DeepL requires a Free or Paid API key, and Kagi Translate requires a session token, not the complete URL, taken from the Kagi settings page and pasted in as an API key. The open source options are LibreTranslate and Lingva, each of which can point at any public instance, with the project running its own at lt.dialectapp.org and lingva.dialectapp.org as the defaults.

For a Linux user, that combination is the interesting part. A hosted service gives the best answer quality you have access to; a self-hosted LibreTranslate instance keeps the traffic inside your own network. Dialect lets you have both without learning two different interfaces, which is the practical reason to pick it over opening a browser tab.

The feature list is short and practical rather than expansive: translation history, automatic language detection, text to speech, and clipboard buttons. There is no batch mode, no document import and no terminology management in what the README documents.

Getting Dialect installed on Fedora, Debian, Arch or Flathub

Dialect ships through the normal channels for a GNOME application, and the README gives a concrete command for each of the two distribution packages it names.

On Fedora, available for Fedora 33 and later:

sudo dnf install dialect

On Debian, available in Debian 12 and later:

sudo apt-get install dialect

Arch users have two options rather than one. The stable version comes from the official Extra repository as the dialect package, while the latest git revision is available as an AUR package named dialect-git. That distinction matters for a reviewer: the AUR package tracks unreleased commits, so a user who wants the state of the main branch and a user who wants the last tagged release are running different code, and the README does not say which is recommended for daily use.

Flathub is listed as well, with a badge pointing at the app's Flathub entry, and the application id visible in the README's icon reference is app.drey.Dialect. The sandboxed Flatpak route is the one that suits a system where you do not want to install the Meson and Ninja toolchain at all.

Building from Git when the package versions are not enough

The build path is documented in detail, and the dependency list is longer than most people expect for a translation front end. The requirements are Python 3 at 3.10 or newer, PyGObject 3.51.0 or newer, GTK4 4.17.5 or newer, libadwaita 1.7.0 or newer, libsoup 3.0 or newer, libsecret, libspelling, GStreamer 1.0, Meson, Ninja, gTTS, and Beautiful Soup. The version floors on GTK4 and libadwaita are high, which means an older distribution will not build this from source without a newer graphics stack.

The clone and install sequence is:

git clone --recurse-submodules https://github.com/dialect-app/dialect.git
cd dialect
meson builddir --prefix=/usr/local
sudo ninja -C builddir install

The --recurse-submodules flag is not decoration. The repository root contains a .gitmodules entry and a subprojects directory, so the submodules hold dependencies the build expects to find.

For development the README recommends running a local build rather than installing, which avoids touching system paths:

meson builddir
meson configure builddir -Dprefix=$(pwd)/builddir/testdir
ninja -C builddir install
ninja -C builddir run

Two Python packages are pulled in from the Python packaging side. The pyproject.toml lists beautifulsoup4 and gtts as dependencies, and if official packages are not available for the Python dependencies, the README says they can be installed from pip:

pip install gtts

Those two are also how the text to speech feature and the HTML scraping of some providers are implemented, which explains why Beautiful Soup appears in the requirements of a translation client at all.

Text to speech and scraping are the parts that reach outside the API

It is worth being precise about how Dialect gets its text to speech, because the feature list says only text to speech and the dependency list says gTTS, and the two together mean the audio is produced by a Google translation text to speech service rather than by a local speech engine. gTTS is listed both in the README requirements and as a pinned dependency in the pyproject.toml at gtts>=2.5.4, and in the exported requirements file it is pinned exactly to gtts==2.5.4 alongside beautifulsoup4==4.14.3.

The Beautiful Soup dependency points the same way. Several of the listed providers, Google Translate among them, do not expose a public API for casual use, so a client that wants to work with them has to fetch a page and parse the result out of the HTML. That is a reasonable engineering choice, and it is also the fragile part of the design, because an HTML change on the provider side is invisible to the client until the output stops being produced.

The open source providers avoid that fragility. LibreTranslate and Lingva expose a documented HTTP interface, which is why a self-hosted instance is a supported configuration rather than a workaround. If you care about predictable behaviour over convenience, pointing Dialect at a self-hosted LibreTranslate or Lingva instance is the configuration with fewer dependencies on someone else's markup.

A related point about credentials: libsecret and libspelling are in the requirements, and the provider configuration, including API keys for DeepL and the Kagi session token, is stored per account rather than in a shared config file. Dialect is built for a single desktop user rather than for a shared machine with several accounts.

What Dialect cannot do, and where the alternatives sit

The honest limitation is that Dialect adds no translation capability of its own. Offline use is not available, because every provider in the list is a network service. There is no indication in the README of any local model, no caching of previously translated text, and no guarantee that a self-hosted instance behaves identically to the public one.

The alternative approach worth naming is the browser. A hosted translator in a browser tab requires no installation and no API key, and it is what most people use. Dialect wins on the desktop integration points that a browser cannot offer cleanly: a clipboard button that moves text in and out, a native window that fits the GNOME theme, and a provider list that includes self-hosted instances.

The other alternative is a dedicated offline translator built on a local model, which works with no network at all. The difference in approach is fundamental rather than incremental: such a tool translates on your machine with no service dependency, while Dialect gives you a choice of seven remote services and a desktop shell. If your constraint is confidentiality of the text and you have no self-hosted instance to point at, neither approach to Dialect satisfies it, because even LibreTranslate on a public instance is someone else's server.

One more comparison is fair. Since Dialect is a GTK application, there is a version of the same idea as a web app served by a local provider, and some Linux distributions ship a browser-based translator. Dialect's argument is native integration and the choice of provider, not translation quality, which it does not control.

Release cadence, licence and the state of the repository

The release history shows a project that ships infrequently. Version 2.6.1 is dated 2025-07-27, version 2.6.0 is dated 2025-07-23, and version 2.5.0 is dated 2024-10-06. The last push to the repository was on 2026-05-12, which is more recent than any tagged release, so work continues on the main branch without a corresponding version. The pyproject.toml still reads version = 2.6.0, so a source build from the main branch does not necessarily match the newest release either.

The repository is not archived. It contains a NEWS.md file for release notes, a po directory for gettext translations, a dialect.doap metadata file, and a subprojects directory for the build's bundled dependencies. Translations are handled through Weblate, and the README asks for help extending the language coverage, noting that Dialect has already been translated into many languages. Contributions go through pull requests, with the convention that major changes should start with an issue so the design can be discussed first.

The licence is the GNU General Public License 3 or later, which is a copyleft licence. For a desktop application that you install on your own machine, that means redistribution terms apply to anyone who ships a modified build, and a distributor packaging Dialect in a distribution repository is bound by them. That is a normal choice for a GNOME application and it matches how comparable projects are licensed, but it does mean a commercial redistribution of a modified Dialect needs a review that this article cannot provide.

Editorial conclusion

Adopt Dialect if you work on GNOME and want one desktop translation client that can switch between a hosted service and a self-hosted LibreTranslate or Lingva instance, and if you care that your history stays on your machine rather than in a browser. Do not adopt it as an offline translator, since every provider it lists is reached over the network, and do not expect an offline speech mode since the text to speech feature is backed by gTTS. Verify first that the provider you intend to use is one of the listed entries, that DeepL, Kagi or any other API-backed service is configured with a key you supply, and that the build you install matches the current release, since the last push was on 2026-05-12 while the newest tagged release is 2.6.1 from 2025-07-27.

Frequently asked questions

Official sources

1. dialect-app/dialect on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases