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.

Translation

Weblate considers translatable content in principle to be a Project, which is assigned all the parts to be translated that belong together (Figure 1). One example is the translation of an application into several languages with the corresponding documentation.

The project forms the basis, above which are the components and the individual translations (Figure 2). The components define the VCS repositories, which in turn contain the files to be translated. The tool supports a whole range of translation formats.

The translation process is based on Git's push and pull principle. When developers make changes, they push them into the VCS repositories. Weblate pulls the changes from the repositories. If Weblate finds changes in the translations, it informs the translators, depending on the settings. The translators in turn deliver their work in the interface.

When the translation is finished, the commit follows through Weblate to the local repository. Depending on the settings, the tool then pushes back the finished translation. Weblate is thus suitable for continuous localization.

Conflict Potential

The merge phase is not completely free of potential conflicts. Users are therefore advised to make sure when updating the translation files that one component does not have multiple change files outstanding (Figure 3). To prevent this state, all existing changes can be pushed, during which the translation is locked until the desired changes have been made.

Weblate has set up a demo system [5] that you can manage online. There you will find the basic user interface with menu navigation and translation tasks. You can also make entries, look at the suggestions of other participants, and define languages.