# django-rosetta puts a gettext catalog editor inside the Django admin > Rosetta is a Django application that reads and writes your gettext catalogs from a web interface, and it is designed to be added and removed without touching your database, because it exports no models. It also offers machine translation as a first pass through DeepL, OpenAI, Google Translate and other services. **mbi/django-rosetta** — Rosetta is a Django application that eases the translation process of your Django projects - Repository: https://github.com/mbi/django-rosetta - Stars: 1,154 · Forks: 203 - Language: Python - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/mbi-django-rosetta ## The problem is the text editor Rosetta is a Django application that facilitates the translation process of Django projects, and its feature list is short enough to read in one go. It reads and writes your project's gettext catalogues, the po and mo files. It is installed and uninstalled in under a minute. It uses Django's own admin interface CSS, so it looks like part of the site rather than a third party tool bolted on. And it provides automatic translations through DeepL, OpenAI, Google Translate and more. The problem it addresses is not that translation is hard, it is that translation happens in the wrong tool. A Django project with translations has a set of .po files, which are text with a specific, slightly awkward format, and a set of .mo files, which are compiled binaries. Translating them means editing text files by hand, keeping the format intact, and then remembering to recompile. Non developers, which is to say most of the people who translate a project, do none of that comfortably. Rosetta turns that into a form. A translator opens a page, sees the string, sees the context, types the translation, and saves. The catalogue is written for you, in the format gettext expects, and the compile step is still a normal Django command. The audience is therefore two groups: the developer who wants translations to actually get done, and the volunteer or colleague who is willing to translate but not to touch a .po file. The second group is what the tool is really for. The package is published to PyPI as django-rosetta, the licence is MIT, and the documentation lives at django-rosetta.readthedocs.org. ## No models means no tables and a clean uninstall The design decision that makes Rosetta easy to adopt is stated early and is unusual for a Django app. Because it does not export any models, Rosetta does not create any tables in your project's database. It can be installed and uninstalled by simply adding and removing a single entry in your INSTALLED_APPS setting and a single line in the main urls.py file. That is a bigger deal than it sounds. A Django application that ships migrations leaves you with tables in your database, and removing it later means either leaving the tables behind, or writing and running a migration to drop them, and in a project with several environments that is a small but real chore. An application that stores nothing in your database has no such residue. You can add it for a translation sprint, run the sprint, and take it out again, and your database is exactly as it was. The other half of the claim, that it installs and uninstalls in under a minute, follows from the same design. There is no data to migrate in or out, so the operation is an edit to two files. The second point about the feature list is the visual one: it uses Django's admin interface CSS. The translation interface is therefore styled with the same components as the rest of your admin, which matters for a tool that volunteers use, because it looks like part of the application they already know how to navigate. The two things Rosetta deliberately is not: it is not a model defining tool, and it is not a place to store translation memory. Both are the consequences of the no tables decision, and both are things to confirm you do not need before installing. ## Machine translation is a first pass, not an answer The automatic translation feature is the one that changes the workflow the most, and it is also the one that needs a caveat. Rosetta provides automatic translations via DeepL, OpenAI, Google Translate and more. In practice this means that when a string has no translation yet, the editor can fill it in from a machine translation service, and a human then corrects it. The effect on a project is a change in the shape of the work: instead of a translator facing an empty form, they face a draft, and the task becomes review and correction rather than composition. That is a genuine saving, but it changes what the tool is for. A machine translation is a starting point, and the person reviewing it is accountable for the result. A project that merges machine output into its .po files without a review step is shipping unreviewed text in every supported language, and the review step is the part the tool does not provide. The list of providers is worth noting for a different reason. DeepL, OpenAI and Google Translate are the three most obvious choices, and the phrase and more means the provider set is not fixed, which matters for a project whose users are in regions where one of those services is not reachable, or whose policy forbids sending strings to a particular vendor. Sending your source strings to an external translation service is also a data flow decision that belongs to whoever owns the strings, not to the tool. The honest framing is that Rosetta is a catalogue editor with a machine translation assistant attached, and the value is in the review workflow, not in the automation. ## The Django floor has moved four times in a few years The README keeps a running note of the Django requirement per release, and it is a useful thing to read before pinning a version. As of version 0.9.0 django-rosetta requires Django 1.11 or later. As of version 0.9.6 it requires Django 2.2 or later. As of version 0.9.9 it supports Django 3.2 or later. And as of version 0.10.0 it requires Django 4.2 or later. Four moves across the 0.9 and 0.10 lines tells you the project tracks the supported Django versions rather than being frozen, which is the right behaviour for an application that plugs into the admin and the URL configuration. The packaging metadata tells you where the current line stands. The setup.py declares the framework classifiers for Django 4.2 and Django 5.0, and the project version is read at build time rather than hard coded: ```python setup( name="django-rosetta", version=__import__("rosetta").get_version(limit=3), description="A Django application that eases the translation of Django projects", long_description=long_description, author="Marco Bonetti", ``` Reading the version from the package itself, with a limit on the number of components, is the pattern that keeps a changelog and the installed version from drifting apart. The classifiers also record the development status as Beta, the intended audience as developers, the topics as localization and internationalization, and the operating system as independent. For an adopter, the practical check is that your Django version is in the range the current release supports, and that the classifiers in the artefact you install match your project, since the note in the readme and the classifier list are written at different times. ## A small tool with a careful import layout The import configuration is where a project like this shows how much attention it pays to the details of a shared codebase. The isort configuration in pyproject.toml treats Django as its own category: ```toml [tool.isort] profile = "black" lines_after_imports = 2 multi_line_output = 3 order_by_type = true known_django = "django" known_django_third_party = "django_*" known_first_party = "apps,rosetta" ``` The sections list in the same file puts Django imports after the third party ones and before the first party ones, and the known_django_third_party pattern of django_* is the way to catch packages such as django_rosetta itself, or the many third party packages that share the prefix. Migrations are skipped, because Django's generated migration files are not worth reordering. The black configuration uses a line length of 88 and targets Python 3.8, and the exclusion list covers the usual build and virtual environment directories. The rest of the repository is small and well organised. There is the rosetta/ package itself, a docs/ directory, a testproject/ directory which is the Django project used for testing, a CHANGES file, a MANIFEST.in, a tox.ini for the test matrix, a .readthedocs.yaml for the documentation build, a .pre-commit-config.yaml, a .flake8 and a .prettierrc and an .eslintrc.js, and a SECURITY.md. The presence of a testproject/ directory is worth a mention, because it means the application is tested inside a real Django project rather than in isolation, which is the only way to test an app whose whole surface is an admin page and a URL. The default branch is develop, with the released versions tagged from it, and the last push was on 2026-07-30 with the repository not archived. The recent releases are 0.10.1 on 2024-09-27, 0.10.2 on 2025-04-03 and 0.10.3 on 2025-12-07. ## Conclusion django-rosetta suits a Django project that ships translations and wants translators to work in a browser rather than in a text editor, and it suits a team that wants machine translation to produce a first draft a human then reviews. It is the wrong choice for a project that does not use gettext, since the entire model is the po and mo catalogue, and a poor match if you want a translation memory, a glossary or per string context, because the tool is a catalogue editor rather than a translation platform. Before adopting, confirm your Django version is within the supported range, check that the machine translation provider you use is one it supports, and decide who is accountable for reviewing the machine output before it reaches a .po file you merge. ## FAQ ### Does django-rosetta create tables in my database? No. Because it does not export any models, Rosetta does not create any tables in your project's database, and it can be installed and uninstalled by adding or removing a single INSTALLED_APPS entry and a single line in your main urls.py file. ### Which Django versions does django-rosetta support? The readme records the requirement moving over time: Django 1.11 or later from version 0.9.0, 2.2 or later from 0.9.6, 3.2 or later from 0.9.9, and 4.2 or later from 0.10.0. The packaging metadata lists the Django 4.2 and 5.0 framework classifiers. ### Which translation services can django-rosetta use? Automatic translations are provided through DeepL, OpenAI, Google Translate and more, so the output is a first pass that still needs a human to review it before it is merged into your catalogues. ### How do I install django-rosetta? Install the django-rosetta package from PyPI, add 'rosetta' to INSTALLED_APPS, and add one line to your main urls.py file. The full instructions are in the online documentation at django-rosetta.readthedocs.org, and the project is MIT licensed. ## Sources - [Issues](https://github.com/mbi/django-rosetta/issues) - [License: MIT](https://github.com/mbi/django-rosetta/blob/develop/LICENSE) - [mbi/django-rosetta on GitHub](https://github.com/mbi/django-rosetta) - [README](https://github.com/mbi/django-rosetta/blob/develop/README.md) - [Releases](https://github.com/mbi/django-rosetta/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mbi-django-rosetta