Weblate organizes translatable content into tree like structure. The toplevel object is Project, which should hold all translations which belong together (for example translation of an application in several versions and/or documentation). On the next level, there is Subproject, which is actually the resource to translate. Here you define Git repository to use and mask of files to translate. Bellow Subproject there are individual translations, which are handled automatically by Weblate as the translation files (matching mask defined in Subproject) appear in Git repository.
Administration of Weblate is done through standard Django admin interface, which is available under /admin/ URL.
All translation resources need to be available as Git repositories and are organized as project/subproject structure.
Weblate supports wide range of translation formats supported by translate toolkit, see Supported formats for more information.
Weblate does support both multilingual and monolingual formats. For easier translating of monolingual formats, you should provide template file, which contains mapping of message IDs to source language (usually English).
To add new resource to translate, you need to create translation project first. The project is sort of shelf, in which real translations are folded. All subprojects in same project share suggestions and dictionary, also the translations are automatically propagated through the all subproject in single project (unless disabled in subproject configuration).
The project has only few attributes giving translators information about project.
The commit message on each commit Weblate does, it can use following format strings in the message:
There are also additional features which you can control, like automatic pushing of changes (see also Pushing changes), merge or rebase (see Merge or rebase), git committer name or maintaining of Translation-Team header.
Subproject is real resource for translating. You enter Git repository location and file mask which files to translate and Weblate automatically fetches the Git and finds all matching translatable files.
Should the language definition for translation be missing, empty definition is created and named as “cs_CZ (generated)”. You should adjust the definition and report this back to Weblate authors so that missing language can be included in next release.
The subproject contains all important parameters for working with Git and getting translations out of it:
Git repository used to pull changes.
This can be either real Git URL or weblate://project/subproject indicating that Git repository should be shared with another subproject.
URL of repository browser to display source files (location where messages are used). When empty no such links will be generated.
For example on GitHub, you would use something like https://github.com/nijel/weblate-hello/blob/%(branch)s/%(file)s#L%(line)s.
Fetching Git repository and importing translations to Weblate can be lengthy process depending on size of your translations. Here are some tips to improve this situation:
You can put in place Git repository which will be used by Weblate. The repositories are stored in path defined by GIT_ROOT in settings.py in <project>/<subproject> directories.
This can be especially useful if you already have local clone of this repository and you can use --reference option while cloning:
git clone \
--reference /path/to/checkout \
git://github.com/nijel/weblate.git \
weblate/repos/project/subproject
The default configuration is useful for testing and debugging Weblate, while for production setup, you should do some adjustments. Many of them have quite big impact on performance. Please check Production setup for more details, especially:
Some quality checks can be quite expensive and if you don’t need them, they can save you some time during import. See CHECK_LIST for more information how to configure this.
In case you have project with dozen of po files, you might want to import all at once. This can be achieved using import_project.
First you need to create project which will contain all subprojects and then it’s just a matter of running import_project.
See also
In case you want Weblate to access private repository it needs to get to it somehow. Most frequently used method here is based on SSH. To have access to such repository, you generate SSH key for Weblate and authorize it to access the repository.
You also need to verify SSH host keys of servers you are going to access.
You can generate or display key currently used by Weblate in the admin interface (follow SSH keys link on main admin page).
Note
The keys need to be without password to make it work, so be sure they are well protected against malicious usage.
If you need to access http/https Git repositories using a proxy server, you need to configure Git to use it.
This can be configured using the http_proxy, https_proxy, and all_proxy environment variables (check cURL documentation for more details) or by enforcing it in Git configuration, for example:
git config --global http.proxy http://user:password@proxy.example.com:80
Note
The proxy setting needs to be done in context which is used to execute Weblate. For the environment it should be set for both server and cron jobs. The Git configuration has to be set for the user which is running Weblate.
Fulltext search is based on Whoosh. You can either allow Weblate to directly update index on every change to content or offload this to separate process by OFFLOAD_INDEXING.
The first approach (immediate updates) allows more up to date index, but suffers locking issues in some setup (eg. Apache’s mod_wsgi) and produces more fragmented index.
Offloaded indexing is always better choice for production setup - it only marks which items need to be reindexed and you need to schedule background process (update_index) to update index. This leads to faster response of the site and less fragmented index with cost that it might be slightly outdated.