Translation projects

Translation organization

Weblate organizes translatable content into tree like structure. The toplevel object is Project configuration, 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 Component configuration, which is actually the component to translate. Here you define VCS repository to use and mask of files to translate. Bellow Component configuration there are individual translations, which are handled automatically by Weblate as the translation files (matching mask defined in Component configuration) appear in VCS repository.

Administration

Administration of Weblate is done through standard Django admin interface, which is available under /admin/ URL. Once logged in as user with proper privileges, you can access it using wrench icon in top navigation:

../_images/admin-wrench.png

Here you can manage objects stored in the database, such as users, translations and other settings:

../_images/admin.png

In the Reports section you can check status of your site, tweak it for Production setup or manage SSH keys to access Private repositories.

All sections below you can manage database objects. The most interesting one is probably Weblate translations, where you can manage translatable projects, see Project configuration and Component configuration.

Adding new components

All translation components need to be available as VCS repositories and are organized as project/component structure.

Weblate supports wide range of translation formats (both bilingual and monolingua) supported by translate toolkit, see Supported formats for more information.

Adding project

First you have to add project, which will serve as container for all components. Usually you create one project for one piece of software or book (see Project configuration for information on individual parameters):

../_images/add-project.png

Ver también

Project configuration

Bilingual components

Once you have added a project, you can add translation compontents to it (see Component configuration for information on individual parameters):

../_images/add-component.png

Ver también

Component configuration

Monolingual components

For easier translating of monolingual formats, you should provide template file, which contains mapping of message IDs to source language (usually English) (see Component configuration for information on individual parameters):

../_images/add-component-mono.png

Ver también

Component configuration

Project configuration

To add new component to translate, you need to create translation project first. The project is sort of shelf, in which real translations are folded. All components in same project share suggestions and dictionary, also the translations are automatically propagated through the all component in single project (unless disabled in component configuration).

The project has only few attributes giving translators information about project:

Project website
URL where translators can find more information about the project.
Mailing list
Mailing list where translators can discuss or comment translations.
Translation instructions
URL where you have more detailed instructions for translators.
Push on commit
Whether any committed changes should be automatically pushed to upstream repository.
Set Translation-Team header
Whether Weblate should manage Translation-Team header (this is GNU Gettext only feature right now).
Enable ACL
Enable per project access control, see Per project access control for more details.
Enable hooks
Whether unauthenticated Notification hooks will be enabled for this repository.
Owner
You can also configure project owner, who will always get important notifications about project and will have additional privileges to control translations within this project (see Access control).

Adjusting interaction

There are also additional features which you can control, like automatic pushing of changes (see also Pushing changes) or maintaining of Translation-Team header.

Component configuration

Component is real component for translating. You enter VCS repository location and file mask which files to translate and Weblate automatically fetches the VCS 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 component contains all important parameters for working with VCS and getting translations out of it:

Source code repository

VCS repository used to pull changes.

This can be either real VCS URL or weblate://project/component indicating that the repository should be shared with another component.

Repository push URL

Repository URL used for pushing, this is completely optional and push support will be disabled when this is empty.

Nota

Weblate currently does not support HTTP authentication on push URLs

Repository browser

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.

Exported repository URL
URL where changes made by Weblate are exported. This is important when Continuous translation is not used or when there is need to manually merge changes.
Repository branch
Which branch to checkout from the VCS and where to look for translations.
File mask

Mask of files to translate including path. It should include one * replacing language code (Weblate can handle language names as well, but it is recommended to use ISO 639-1 language codes). In case your repository contains more than one translation files (eg. more Gettext domains), you need to create separate component for each.

For example po/*.po or locale/*/LC_MESSAGES/django.po.

Monolingual base language file
Base file containing strings definition for Monolingual components.
Edit base file
Whether to allow editing of base file for Monolingual components.
Base file for new translations
Base file used to generate new translations, eg. .pot file with Gettext.
File format
Translation file format, see also Supported formats.
Source string bug report address
Email address used for reporting upstream bugs. This address will also receive notification about any source string comments made in Weblate.
Locked
You can lock the translation to prevent updates by users.
Allow translation propagation

You can disable propagation of translations to this component from other components within same project. This really depends on what you are translating, sometimes it’s desirable to have same string used.

It’s usually good idea to disable this for monolingual translations unless you are using same IDs across whole project.

Post-update script
One of scripts defined in POST_UPDATE_SCRIPTS which is executed after receiving update. This can be used to update the translation files.
Pre-commit script
One of scripts defined in PRE_COMMIT_SCRIPTS which is executed before commit. This can be used to generate some metadata about translation or to generate binary form of a translation.
Post-commit script
One of scripts defined in POST_COMMIT_SCRIPTS which is executed after commit. This can be used to notify external parties about the change.
Post-push script
One of scripts defined in POST_PUSH_SCRIPTS which is executed after push to remote repository. This can be used to generate notify external parties about the change in repository (i.e. create pull request).
Post-add script
One of scripts defined in POST_ADD_SCRIPTS which is executed when new translation has been added. This can be used to adjust additional files in the repository when adding new translation.
Additional commit files

Additional files to include in the commit (separated by newline), usually this one is generated by the pre commit or post add scripts described above.

Supply the %(language)s in the path like this: path/to/addditinal/%(language)s_file.example

Save translation history
Whether to store history of translation changes in database.
Suggestion voting
Enable voting for suggestions, see Suggestion voting.
Autoaccept suggestions
Automatically accept voted suggestions, see Suggestion voting.
Quality checks flags
Additional flags to pass to quality checks, see Customizing checks.
Translation license
License of this translation.
License URL
URL where users can find full text of a license.
New language
How to handle requests for creating new languages. Please note that availability of choices depends on the file format, see Supported formats.
Merge style
You can configure how the updates from upstream repository are handled. This might not be supported for some VCS. See Merge or rebase for more details.
Commit message
Message used when committing translation, see Commit message formatting.
Committer name
Name of commiter used on Weblate commits, the author will be always the real translator. On some VCS this might be not supported. Default value can be changed by DEFAULT_COMMITER_NAME.
Committer email
Email of commiter used on Weblate commits, the author will be always the real translator. On some VCS this might be not supported. Default value can be changed by DEFAULT_COMMITER_EMAIL.
Language filter
Regular expression which is used to filter translation when scanning for file mask. This can be used to limit list of languages mnaged by Weblate (eg. ^(cs|de|es)$ will include only those there languages. Please note that you need to list language codes as they appear in the filename.

Commit message formatting

The commit message on each commit Weblate does, it can use following format strings in the message:

%(language)s
Language code
%(language_name)s
Language name
%(component)s
Component name
%(project)s
Project name
%(total)s
Total strings count
%(fuzzy)s
Fuzzy strings count
%(fuzzy_percent)s
Fuzzy strings percent
%(translated)s
Translated strings count
%(translated_percent)s
Translated strings percent

Ver también

Does Weblate support other VCS than Git and Mercurial?, Processing repository with scripts

Importing speed

Fetching VCS repository and importing translations to Weblate can be lengthy process depending on size of your translations. Here are some tips to improve this situation:

Clone Git repository in advance

You can put in place Git repository which will be used by Weblate. The repositories are stored in vcs directory in path defined by DATA_DIR in settings.py in <project>/<component> 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/component

Optimize configuration

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:

Disable not needed checks

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.

Automatic creation of components

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 components and then it’s just a matter of running import_project.

Ver también

Management commands

Accessing repositories

Private repositories

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).

If you are trying to connect to a GitHub repository either use the SSH address (eg. git@github.com:nijel/weblate.git) or generate personal access token (see Creating an access token for command-line use) and include it in the URL. The full URL should look like https://user:your_access_token@github.com/nijel/weblate.git.

On GitHub, you can add the key to only one repository. If you plan to access more of them, it might be better to create separate user for that, assign him Weblate’s SSH key and grant him access to all reposities.

Nota

The keys need to be without password to make it work, so be sure they are well protected against malicious usage.

Using proxy

If you need to access http/https VCS repositories using a proxy server, you need to configure VCS 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 VCS configuration, for example:

git config --global http.proxy http://user:password@proxy.example.com:80

Nota

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 VCS configuration has to be set for the user which is running Weblate.

Ver también

http://curl.haxx.se/docs/manpage.html, http://git-scm.com/docs/git-config