Polyglot

Developer Michal Cihar coined the artificial word "Weblate" by combining "web" and "translate." Closely linked to a version control system (VCS), Weblate is written in Python and used for continuous translation of text (e.g., in internationally active projects). Thanks to its adaptable structure, it can also be used for smaller projects.

Weblate currently supports the integration of about 350 languages as a basic framework. However, these are only basic definitions, such as the language name, plural formation, text direction, and language code (usually ISO 639-1). You can create your own language definitions or change existing ones. Depending on the tool's settings, the translation itself then comes from the web community or a defined set of people, as well as through integrating machine translation [1], such as DeepL, Amazon Translate, or Google Translate. Weblate itself can also act as a machine translator by accessing the Whoosh full-text engine.

Installation

Cihar cites three basic installation methods. The first relies on Docker, which is recommended for those who are satisfied with the existing functionality of Weblate and do not want to adapt the code themselves, although this is also possible. With the second option, again the code of Weblate remains unchanged; it requires a Python environment, which is set up with virtualenv. The third option is an installation from the source code that resides on GitHub [2].

The Git repositories can also be installed directly in OpenShift. The setup is described in detail in the Weblate documentation [3]. Weblate also offers a hosted version [4], in which the setup and hosting are handled for a charge. Prices start at around EUR20 per month.

The minimum requirements for the tool are 2GB of memory, a dual-core CPU, and 1GB of disk space. However, more memory is useful for caching at all levels, starting with the filesystem and database. More CPU cores, on the other hand, would boost performance with an increasing number of users.

On the software side, the system also needs to provide Python 2.7 or 3.4 or later and a database compatible with Django; PostgreSQL is cited as a reference. If you use MySQL, be prepared to deal with potential incompatibility issues with UTF-8 encoding and other Unicode characters used in MySQL by changing the encoding to utf8mb4.

Settings

The administrator has control over a number of settings that affect both the text that needs to be translated and the users involved in the translation, including access rights. Weblate works as a version manager with a graphical user interface.

After setting up the tool for production, you will find some helpers that pop up as warnings in the form of red exclamation marks. In production use, switching off Django's debug mode is also recommended; otherwise, it displays all requests and user data. To notify admins of various events, you add their email addresses.

Registration and Access

By default, Weblate uses python-social-auth to register new users (i.e., translators) and leaves the authentication work to the integrated solution in Django, which you can adapt to your taste with the options offered there, including for third-party solutions (e.g., GitLab). In principle, however, Weblate expects a validated email address from the selected authentication service. The Weblate access system is fine-grained, adjustable, and based on group and role models.

If an access control list (ACL) is activated, all users are blocked until the admin defines the access rights. Four basic settings can be selected in the GUI: Public , Protected , Private , and Custom . If access is set to Public , the translation project is visible to everyone, and everyone can enter translations. The Protected state makes the translations visible to everyone, but only certain users are allowed to translate. In Private mode, only certain users can view and translate the project. Custom means that Weblate is not responsible for access management.

Privileges can be granted to groups or individual users. For simplicity, Weblate offers predefined groups (e.g., Administration , Languages , Screenshots ). Languages participants would then be responsible for managing the translated languages and would be allowed to add new translations. Screenshots participants would be able to add screenshots to certain strings.