Welcome to Weblate’s documentation!¶

Database setup for Weblate

WEBLATE_IP_PROXY_HEADER¶

Lets Weblate fetching the IP address from any given HTTP header. Use this when using a reverse proxy in front of the Weblate container.

Enables IP_BEHIND_REVERSE_PROXY and sets IP_PROXY_HEADER.

Example:

environment:
  - WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR

WEBLATE_REQUIRE_LOGIN¶

Configures login required for the whole of the Weblate installation using LOGIN_REQUIRED_URLS.

Example:

environment:
  - WEBLATE_REQUIRE_LOGIN=1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶: Adds URL exceptions for login required for the whole Weblate installation using LOGIN_REQUIRED_URLS_EXCEPTIONS.

WEBLATE_GOOGLE_ANALYTICS_ID¶: Configures ID for Google Analytics by changing GOOGLE_ANALYTICS_ID.

WEBLATE_GITHUB_USERNAME¶: Configures GitHub username for GitHub pull-requests by changing GITHUB_USERNAME.

Ver también

Pushing changes to GitHub as pull request, Setting up hub

WEBLATE_SIMPLIFY_LANGUAGES¶: Configures the language simplification policy, see SIMPLIFY_LANGUAGES.

WEBLATE_AKISMET_API_KEY¶: Configures the Akismet API key, see AKISMET_API_KEY.

Machine translation settings¶

WEBLATE_MT_DEEPL_KEY¶: Enables DeepL machine translation and sets MT_DEEPL_KEY

WEBLATE_MT_GOOGLE_KEY¶: Enables Google Translate and sets MT_GOOGLE_KEY

WEBLATE_MT_MICROSOFT_COGNITIVE_KEY¶: Enables Microsoft Cognitive Services Translator and sets MT_MICROSOFT_COGNITIVE_KEY

WEBLATE_MT_MYMEMORY_ENABLED¶: Enables MyMemory machine translation and sets MT_MYMEMORY_EMAIL to WEBLATE_ADMIN_EMAIL.

WEBLATE_MT_GLOSBE_ENABLED¶: Enables Glosbe machine translation.

Authentication settings¶

LDAP¶

WEBLATE_AUTH_LDAP_SERVER_URI¶

WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶

WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶

LDAP authentication configuration.

Example:

environment:
  - WEBLATE_AUTH_LDAP_SERVER_URI=ldap://ldap.example.org
  - WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE=uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  - WEBLATE_AUTH_LDAP_USER_ATTR_MAP=full_name:name,email:mail

Ver también

LDAP authentication

GitHub¶

WEBLATE_SOCIAL_AUTH_GITHUB_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_SECRET¶: Enables GitHub authentication.

BitBucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET¶: Enables Bitbucket authentication.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Enables Facebook OAuth 2.

Google¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶: Enables Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Enables GitLab OAuth 2.

Azure Active Directory¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Enables Azure Active Directory authentication, see Microsoft Azure Active Directory.

Azure Active Directory with Tenant support¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: Enables Azure Active Directory authentication with Tenant support, see Microsoft Azure Active Directory.

Other authentication settings¶

WEBLATE_NO_EMAIL_AUTH¶: Disables email authentication when set to any value.

PostgreSQL database setup¶

The database is created by docker-compose.yml, so these settings affect both Weblate and PostgreSQL containers.

Ver también

POSTGRES_PASSWORD¶: PostgreSQL password.

POSTGRES_USER¶: PostgreSQL username.

POSTGRES_DATABASE¶: PostgreSQL database name.

POSTGRES_HOST¶: PostgreSQL server hostname or IP address. Defaults to database.

POSTGRES_PORT¶: PostgreSQL server port. Defaults to none (uses the default value).

Caching server setup¶

Using Redis is strongly recommended by Weblate and you have to provide a Redis instance when running Weblate in Docker. Additionally Memcached is supported for compatibility with older deployments.

Ver también

Enable caching

REDIS_HOST¶: The memcached server hostname or IP address. Defaults to cache.

REDIS_PORT¶: The Memcached server port. Defaults to 6379.

MEMCACHED_HOST¶: The Memcached server hostname or IP address. Defaults to cache.

MEMCACHED_PORT¶: The Memcached server port. Defaults to 11211.

Email server setup¶

To make outgoing email work, you need to provide a mail server.

Ver también

Configuring outgoing email

WEBLATE_EMAIL_HOST¶: Mail server, the server has to listen on port 587 and understand TLS.

Ver también

EMAIL_HOST

WEBLATE_EMAIL_PORT¶: Mail server port. Use if your cloud provider or ISP blocks outgoing connections on port 587.

Ver también

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: Email authentication user, do NOT use quotes here.

Ver también

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶: Email authentication password, do NOT use quotes here.

Ver también

EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_USE_SSL¶: Whether to use an implicit TLS (secure) connection when talking to the SMTP server. In most email documentation, this type of TLS connection is referred to as SSL. It is generally used on port 465. If you are experiencing problems, see the explicit TLS setting WEBLATE_EMAIL_USE_TLS.

Ver también

EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶: Whether to use a TLS (secure) connection when talking to the SMTP server. This is used for explicit TLS connections, generally on port 587. If you are experiencing connections that hang, see the implicit TLS setting WEBLATE_EMAIL_USE_SSL.

Ver también

EMAIL_USE_TLS

Error reporting¶

It is recommended to collect errors from the installation in a systematic way, see Collecting error reports.

To enable support for Rollbar, set the following:

ROLLBAR_KEY¶: Your Rollbar post server access token.

ROLLBAR_ENVIRONMENT¶: Your Rollbar environment, defaults to production.

To enable support for Sentry, set following:

SENTRY_DSN¶: Your Sentry DSN.

SENTRY_PUBLIC_DSN¶: Your Sentry public DSN.

SENTRY_ENVIRONMENT¶: Your Sentry environment, defaults to production.

Further configuration customization¶

You can additionally override the configuration in /app/data/settings-override.py. This is executed after all environment settings are loaded, so it gets completely set up, and can be used to customize anything.

Hub setup¶

In order to use the GitHub’s pull-request feature, you must initialize hub configuration by entering the Weblate container and executing an arbitrary Hub command. For example:

docker-compose exec weblate bash
cd
HOME=/app/data/home hub clone octocat/Spoon-Knife

The username passed for credentials must be the same as GITHUB_USERNAME.

Ver también

Pushing changes to GitHub as pull request, Setting up hub

Select your machine - local or cloud providers¶

With docker-machine you can create your Weblate deployment either on your local machine, or on any large number of cloud-based deployments on e.g. Amazon AWS, Greenhost, and many other providers.

Running Weblate on OpenShift 2¶

This repository contains a configuration for the OpenShift platform as a service product, which facilitates easy installation of Weblate on OpenShift variants (see https://www.openshift.com/ and https://www.okd.io/).

Prerequisites¶

OpenShift Account

You need an account on OpenShift Online (https://www.openshift.com/) or another OpenShift installation you have access to.

You can register a gratis account on OpenShift Online, which allows you to host up to 3 programs gratis.
OpenShift Client Tools

In order to follow the examples given in this documentation, you need to have the OpenShift Client Tools (RHC) installed: https://docs.openshift.com/online/cli_reference/get_started_cli.html

While there are other possibilities to create and configure OpenShift programs, this documentation is based on the OpenShift Client Tools (RHC) because they provide a consistent interface for all described operations.

Installation¶

You can install Weblate on OpenShift directly from Weblate’s GitHub repository with the following command:

# Install Git HEAD
rhc -aweblate app create -t python-2.7 --from-code https://github.com/WeblateOrg/weblate.git --no-git

# Install Weblate 2.10
rhc -aweblate app create -t python-2.7 --from-code https://github.com/WeblateOrg/weblate.git#weblate-3.4 --no-git

The -a option defines the name of your weblate installation, weblate in this instance. Feel free to specify a different name.

The above example installs the latest development version, you can optionally specify tag identifier to the right of the # sign to identify the version of Weblate to install. A list of available versions is available here: https://github.com/WeblateOrg/weblate/tags.

The --no-git option skips the creation of a local Git repository.

You can also specify which database you want to use:

# For MySQL
rhc -aweblate app create -t python-2.7 -t mysql-5.5 --from-code https://github.com/WeblateOrg/weblate.git --no-git

# For PostgreSQL
rhc -aweblate app create -t python-2.7 -t postgresql-9.2 --from-code https://github.com/WeblateOrg/weblate.git --no-git

Default Configuration¶

After installation on OpenShift, Weblate is ready for use and, preconfigured as follows:

SQLite embedded database (DATABASES)
Random admin password
Random Django secret key (SECRET_KEY)
Committing of pending changes if the Cron cartridge is installed (commit_pending)
Weblate machine translations for suggestions, based on previous translations (MT_SERVICES)
Weblate directories (STATIC_ROOT, DATA_DIR, TTF_PATH, avatar cache) set according to OpenShift requirements/conventions.
Django sitename and ALLOWED_HOSTS set to DNS name of your OpenShift program
Email sender addresses set to no-reply@<OPENSHIFT_CLOUD_DOMAIN>, where <OPENSHIFT_CLOUD_DOMAIN> is the domain OpenShift runs under. In case of OpenShift Online it is rhcloud.com.

Ver también

Customize the Weblate Configuration

Retrieve the Admin Password¶

Retrieve the generated admin password using the following command:

rhc -aweblate ssh credentials

Pending Changes¶

Weblate’s OpenShift configuration contains a Cron job which periodically commits pending changes older than a certain age (24h by default). To enable the Cron job you need to add the Cron cartridge and restart Weblate as described in the previous section. You can change the age parameter by setting the environment variable WEBLATE_PENDING_AGE to the desired number of hours, e.g.:

rhc -aweblate env set WEBLATE_PENDING_AGE=48

Customize the Weblate Configuration¶

Customize the configuration of your Weblate installation on OpenShift through the use of environment variables. Override any of Weblate’s settings documented under Configuration using rhc env set by prepending the settings name with WEBLATE_. The variable content is put into the configuration file verbatim, so it is parsed as a Python string, after replacing the environment variables in it (e.g. $PATH). To put in a literal $ you need to escape it as $$.

For example override the ADMINS setting like this:

rhc -aweblate env set WEBLATE_ADMINS='(("John Doe", "john@example.org"),)'

To change the sitetitle, do not forget to include additional quotes:

rhc -aweblate env set WEBLATE_SITE_TITLE='"Custom Title"'

The new settings will only take effect once Weblate is restarted:

rhc -aweblate app stop
rhc -aweblate app start

Restarting using rhc -aweblate app restart does not work. For security reasons only constant expressions are allowed as values. With the exception of environment variables, which can be referenced using ${ENV_VAR}. For example:

rhc -aweblate env set WEBLATE_SCRIPTS='("${OPENSHIFT_DATA_DIR}/examples/hook-unwrap-po",)'

You can check the effective settings Weblate is using by running:

rhc -aweblate ssh settings

This will also print syntax errors in your expressions. To reset a setting to its preconfigured value, just delete the corresponding environment variable:

rhc -aweblate env unset WEBLATE_ADMINS

Ver también

Configuration

Updating¶

It is recommended that you try updates on a clone of your Weblate installation before running the actual update. To create such a clone, run:

rhc -aweblate2 app create --from-app weblate

Visit the newly given URL with a web browser and wait for the install/update page to disappear.

You can update your Weblate installation on OpenShift directly from Weblate’s GitHub repository by executing:

rhc -aweblate2 ssh update https://github.com/WeblateOrg/weblate.git

The identifier to the right of the # sign identifies the version of Weblate to install. For a list of available versions see: https://github.com/WeblateOrg/weblate/tags. Please note that the update process will not work if you modified the Git repository of you Weblate installation. You can force an update by specifying the --force option with the update script. However any changes you made to the Git repository of your installation will be discarded:

rhc -aweblate2 ssh update --force https://github.com/WeblateOrg/weblate.git

The --force option is also needed when downgrading to an older version. Please note that only version 2.0 and newer can be installed on OpenShift, as older versions don’t include the necessary configuration files.

The update script takes care of the following update steps, as described in Generic upgrade instructions.

Install any new requirements
manage.py migrate
manage.py setupgroups –move
manage.py setuplang
manage.py rebuild_index –all
manage.py collectstatic –noinput

Bitnami Weblate stack¶

Bitnami provides a Weblate stack for many platforms at <https://bitnami.com/stack/weblate>. The setup will be adjusted during installation, see <https://bitnami.com/stack/weblate/README.txt> for more documentation.

Weblate in YunoHost¶

The self-hosting project YunoHost provides a package for Weblate. Once you have your YunoHost installation, you may install Weblate as any other application. It will provide you with a fully working stack with backup and restoration, but you may still have to edit your settings file for specific usages.

You may use your administration interface, or this button (it will bring you to your server):

It also is possible to use the commandline interface:

yunohost app install https://github.com/YunoHost-Apps/weblate_ynh

Upgrading Weblate¶

Generic upgrade instructions¶

Before upgrading, please check the current Software requirements as they might have changed. Once all requirements are installed or updated, please adjust your settings.py to match changes in the configuration (consult settings_example.py for correct values).

Always check Version specific instructions before upgrade. In case you are skipping some versions, please follow instructions for all versions you are skipping in the upgrade. Sometimes it’s better to upgrade to some intermediate version to ensure a smooth migration. Upgrading across multiple releases should work, but is not as well tested as single version upgrades.

Nota

It is recommended to perform a full database backup prior to upgrade so that you can roll back the database in case upgrade fails, see Backing up and moving Weblate.

Upgrade configuration file, refer to settings_example.py or Version specific instructions for needed steps.
Upgrade database structure:
```
./manage.py migrate --noinput
```
Collect updated static files (mostly javascript and CSS):
```
./manage.py collectstatic --noinput
```
Update language definitions (this is not necessary, but heavily recommended):
```
./manage.py setuplang
```
Optionally upgrade default set of privileges definitions (you might want to add new permissions manually if you have heavily tweaked access control):
```
./manage.py setupgroups
```
If you are running version from Git, you should also regenerate locale files every time you are upgrading. You can do this by invoking:
```
./manage.py compilemessages
```
Verify that your setup is sane (see also Production setup):
```
./manage.py check --deploy
```
Restart celery worker (see Background tasks using Celery).

Version specific instructions¶

Upgrade from 2.x¶

If you are upgrading from 2.x release, always first upgrade to 3.0.1 (see Upgrade from 2.20 to 3.0) and the continue upgrading in the 3.x series. Upgrades skipping this step are not supported and will break.

Upgrade from 3.0.1 to 3.1¶

Please follow Generic upgrade instructions in order to perform update.

Notable configuration or dependencies changes:

Several no longer needed applications have been removed from INSTALLED_APPS.
The settings now recommend using several Django security features, see SSL/HTTPS.
There is new dependency on the jellyfish module.

Ver también

Upgrade from 3.1 to 3.2¶

Please follow Generic upgrade instructions in order to perform update.

Notable configuration or dependencies changes:

Rate limiting configuration has been changed, please see Rate limiting.
Microsoft Terminology machine translation was moved to separate module and now requires zeep module.
Weblate now uses Celery for several background tasks. There are new dependencies and settings because of this. You should also run Celery worker as standalone process. See Background tasks using Celery for more information.
There are several changes in settings_example.py, most notable Celery configuration and middleware changes, please adjust your settings accordingly.

Ver también

Upgrade from 3.2 to 3.3¶

Please follow Generic upgrade instructions in order to perform update.

Notable configuration or dependencies changes:

The DEFAULT_CUSTOM_ACL settings was replaced by DEFAULT_ACCESS_CONTROL. If you were using that please update your settings.py.
Increase required translate-toolkit version to 2.3.1.
Increase required social auth module versions (2.0.0 for social-auth-core and 3.0.0 for social-auth-app-django).
The CELERY_RESULT_BACKEND should be now configured unless you are using eager mode, see Configuration and defaults.
There is new weblate.middleware.ProxyMiddleware middleware needed if you use IP_BEHIND_REVERSE_PROXY.

Ver también

Upgrade from 3.3 to 3.4¶

Please follow Generic upgrade instructions in order to perform update.

Notable configuration or dependencies changes:

The Celery now uses multiple queues, it is recommended to update to new worker setup which utilizes this, see Background tasks using Celery.
There is new depedency on diff-match-patch and translation-finder.

Ver también

Background tasks using Celery

Upgrading from Python 2 to Python 3¶

Weblate currently supports both Python 2.7 and 3.x. Upgrading existing installations is supported, but you should pay attention to some data stored on the disk as it might be incompatible between these two.

Things which might be problematic include Whoosh indices and file based caches. Fortunately these are easy to handle. Recommended upgrade steps:

Backup your Translation Memory using dump_memory:
```
./manage.py dump_memory > memory.json
```
Upgrade your installation to Python 3.
Delete Translation Memory database delete_memory:
```
./manage.py delete_memory --all
```
Restore your Translation Memory using import_memory.
```
./manage.py import_memory memory.json
```
Recreate fulltext index using rebuild_index:
```
./manage.py rebuild_index --clean --all
```
Cleanup avatar cache (if using file based) using cleanup_avatar_cache.
```
./manage.py cleanup_avatar_cache
```
It is recommended to throw away your caches.

Migrating from Pootle¶

As Weblate was originally written as replacement from Pootle, it is supported to migrate user accounts from Pootle. You can dump the users from Pootle and import them using importusers.

Backing up and moving Weblate¶

Backing up¶

Depending on what you want to save, back up the type data Weblate stores in each respective place.

Database¶

Where this is located depends on your database setup.

The database is the most important storage. Set up regular backups of your database, without it all your translation setup will be gone.

Files¶

If you have enough backup space, simply backup the whole DATA_DIR. This is safe bet even if it includes some files you don’t want. The following sections describe in detail what you should back up and what you can skip.

Dumped data for backups¶

Stored in DATA_DIR /backups.

Weblate dumps various data here, and you can include these files for more complete backups. The files are updated daily (requires a running Celery beats server, see Background tasks using Celery). Currently this includes:

Translation memory dump, in JSON format.

Version control repositories¶

Stored in DATA_DIR /vcs.

The version control repositories contain a copy of your upstream repositories with Weblate changes. If you have push on commit enabled for all your translation components, all Weblate changes are included upstream and you do not have to backup the repositories on the Weblate side. They can be cloned again from the upstream locations with no data loss.

SSH and GPG keys¶

Stored in DATA_DIR /ssh and DATA_DIR /home.

If you are using SSH or GPG keys generated by Weblate, you should back up these locations, otherwise you will loose the private keys and you will have to regenerate new ones.

User uploaded files¶

Stored in DATA_DIR /media.

You should back up user uploaded files (e.g. Visual context for strings).

Translation memory¶

Stored in DATA_DIR /memory.

It is recommended to back up this content using dump_memory in JSON-, instead of binary format, as that might eventually change (and is also incompatible going from Python 2 to Python 3). Weblate prepares this dump daily, see Dumped data for backups.

Fulltext index¶

Stored in DATA_DIR /whoosh.

It is recommended to not backup this and regenerate it from scratch on restore.

Celery tasks¶

The Celery tasks queue might contain some info, but is usually not needed for a backup. At most your will loose updates that have not yet ben processed to translation memory. It is recommended to perform the fulltext or repository updates upon restoring anyhow, so there is no problem in losing these.

Ver también

Restoring¶

Restore all data you have backed up.
Recreate a fulltext index using rebuild_index:
```
./manage.py rebuild_index --clean --all
```
Restore your Translation Memory using import_memory.
```
./manage.py import_memory memory.json
```
Update all repositories using updategit.
```
./manage.py updategit --all
```

Moving a Weblate installation¶

Relocatable your installation to a different system by following the backup and restore instructions above.

Ver también

Upgrading from Python 2 to Python 3

Authentication¶

User registration¶

The default setup for Weblate is to use python-social-auth, a form on the website to handle registration of new users. After confirming their email a new user can contribute or authenticate by using one of the third party services.

You can also turn off registration of new users using REGISTRATION_OPEN.

The authentication attempts are subject to Rate limiting.

Authentication backends¶

The inbuilt solution of Django is used for authentication, including various social options to do so. Using it means you can import the user database of other Django based projects (see Migrating from Pootle).

Django can additionally be set up to authenticate against other means too.

Password authentication¶

The default settings.py comes with a reasonable set of AUTH_PASSWORD_VALIDATORS:

Passwords can’t be too similar to your other personal info.
Passwords must contain at least 6 characters.
Passwords can’t be a commonly used password.
Passwords can’t be entirely numeric.
Passwords can’t consist of a single character or only whitespace.
Passwords can’t match a password you have used in the past.

You can customize this setting to match your password policy.

Additionally you can also install django-zxcvbn-password which gives quite realistic estimates of password difficulty and allows rejecting passwords below a certain threshold.

LDAP authentication¶

LDAP authentication can be best achieved using the django-auth-ldap package. You can install it via usual means:

# Using PyPI
pip install django-auth-ldap>=1.3.0

# Using apt-get
apt-get install python-django-auth-ldap

Advertencia

With django-auth-ldap older than 1.3.0 the Automatic group assignments will not work properly for newly created users.

Nota

There are some incompatibilities in the Python LDAP 3.1.0 module, which might prevent you from using that version. If you get error AttributeError: “module” object has no attribute “_trace_level”, downgrading python-ldap to 3.0.0 might help.

Once you have the package installed, you can hook it into the Django authentication:

# Add LDAP backed, keep Django one if you want to be able to login
# even without LDAP for admin account
AUTHENTICATION_BACKENDS = (
    'django_auth_ldap.backend.LDAPBackend',
    'weblate.accounts.auth.WeblateUserBackend',
)

# LDAP server address
AUTH_LDAP_SERVER_URI = 'ldaps://ldap.example.net'

# DN to use for authentication
AUTH_LDAP_USER_DN_TEMPLATE = 'cn=%(user)s,o=Example'
# Depending on your LDAP server, you might use a different DN
# like:
# AUTH_LDAP_USER_DN_TEMPLATE = 'ou=users,dc=example,dc=com'

# List of attributes to import from LDAP upon login
# Weblate stores full name of the user in the full_name attribute
AUTH_LDAP_USER_ATTR_MAP = {
    'full_name': 'name',
    # Use the following if your LDAP server does not have full name
    # Weblate will merge them later
    # 'first_name': 'givenName',
    # 'last_name': 'sn',
    # Email is required for Weblate (used in VCS commits)
    'email': 'mail',
}

If you can not use direct bind for authentication, you will need to use search, and provide a user to bind for the search. For example:

import ldap
from django_auth_ldap.config import LDAPSearch

AUTH_LDAP_BIND_DN = ""
AUTH_LDAP_BIND_PASSWORD = ""
AUTH_LDAP_USER_SEARCH = LDAPSearch("ou=users,dc=example,dc=com",
    ldap.SCOPE_SUBTREE, "(uid=%(user)s)")

Nota

You should remove 'social_core.backends.email.EmailAuth' from the AUTHENTICATION_BACKENDS setting, otherwise users will be able to set their password in Weblate, and authenticate using that. Keeping 'weblate.accounts.auth.WeblateUserBackend' is still needed in order to make permissions and facilitate anonymous users. It will also allow you to log in using a local admin account, if you have created it (e.g. by using createadmin).

Ver también

Django Authentication Using LDAP, Authentication

CAS authentication¶

CAS authentication can be achieved using a package such as django-cas-ng.

Step one is disclosing the email field of the user via CAS. This has to be configured on the CAS server itself, and requires you run at least CAS v2 since CAS v1 doesn’t support attributes at all.

Step two is updating Weblate to use your CAS server and attributes.

To install django-cas-ng:

pip install django-cas-ng

Once you have the package installed you can hook it up to the Django authentication system by modifying the settings.py file:

# Add CAS backed, keep the Django one if you want to be able to log in
# even without LDAP for the admin account
AUTHENTICATION_BACKENDS = (
    'django_cas_ng.backends.CASBackend',
    'weblate.accounts.auth.WeblateUserBackend',
)

# CAS server address
CAS_SERVER_URL = 'https://cas.example.net/cas/'

# Add django_cas_ng somewhere in the list of INSTALLED_APPS
INSTALLED_APPS = (
    ...,
    'django_cas_ng'
)

Finally, a signal can be used to map the email field to the user object. For this to work you have to import the signal from the django-cas-ng package and connect your code with this signal. Doing this in settings file can cause problems, therefore it’s suggested to put it:

In your app config’s django.apps.AppConfig.ready() method (Django 1.7 and above)
At the end of your models.py file (Django 1.6 and below)
In the project’s urls.py file (when no models exist)

from django_cas_ng.signals import cas_user_authenticated
from django.dispatch import receiver
@receiver(cas_user_authenticated)
def update_user_email_address(sender, user=None, attributes=None, **kwargs):
    # If your CAS server does not always include the email attribute
    # you can wrap the next two lines of code in a try/catch block.
    user.email = attributes['email']
    user.save()

Ver también

Django CAS NG

Configuring third party Django authentication¶

Generally any Django authentication plugin should work with Weblate. Just follow the instructions for the plugin, just remember to keep the Weblate user backend installed.

Ver también

LDAP authentication, CAS authentication

Typically the installation will consist of adding an authentication backend to AUTHENTICATION_BACKENDS and installing an authentication app (if there is any) into INSTALLED_APPS:

AUTHENTICATION_BACKENDS = (
    # Add authentication backend here
    'weblate.accounts.auth.WeblateUserBackend',
)

INSTALLED_APPS = (
    ...
    'weblate',
    # Install authentication app here
)

Access control¶

Distinto en la versión 3.0: Before Weblate 3.0, the privilege system was based on Django, but is now specifically built for Weblate. If you are using an older version, please the consult documentation for that version, the information here will not apply.

Weblate comes with a fine grained privilege system to assign user permissions for the whole instance, or in a limited scope.

The permission system based on groups and roles, where roles define a set of permissions, and groups assign them to users and translations, see Users, roles, groups and permissions for more details.

After installation a default set of groups is created, and you can use those to assign users roles for the whole instance (see Default groups and roles). Additionally when Per project access control is turned on, you can assign users to specific translation projects. More fine-grained configuration can be achieved using Custom access control

Common setups¶

Locking down Weblate¶

To completely lock down your Weblate installation, you can use LOGIN_REQUIRED_URLS to force users to log in and REGISTRATION_OPEN to prevent new registrations.

Site wide permissions¶

To manage permissions for a whole instance, just add users to Users (this is done by default using the Automatic group assignments), Reviewers and Managers groups. Keep all projects configured as Public (see Per project access control).

Per project permissions¶

Set your projects to Protected or Private, and manage users per project in the Weblate interface.

Adding permissions to languages, projects or component sets¶

You can additionally grant permissions to any user based on project, language or a component set. To achieve this, create a new group (e.g. Czech translators) and configure it for a given resource. Any assigned permissions will be granted to members of that group for selected resources.

This will work just fine without additional setup, if using per project permissions. For permissions on the whole instance, you will probably also want to remove these permissions from the Users group, or change automatic assignment of all users to that group (see Automatic group assignments).

Per project access control¶

Nota

By enabling ACL, all users are prohibited from accessing anything within a given project, unless you add the permissions for them to do just that.

You can limit user’s access to individual projects. This feature is turned on by Access control in the configuration of each respective project. This automatically creates several groups for this project, see Predefined groups.

The following choices exist for Access control:

Public: Publicly visible and translatable
Protected: Publicly visible, but translatable only for selected users
Private: Visible and translatable only for selected users
Custom: Weblate does not manage users, see Custom access control.

To allow access to this project, you have to add the privilege either directly to the given user, or group of users in the Django admin interface, or by using user management on the project page, as described in Managing per project access control.

Nota

Even with ACL turned on, some summary info will be available about your project:

Statistics for the whole instance, including counts for all projects.
Language summary for the whole instance, including counts for all projects.

Automatic group assignments¶

You can set up Weblate to automatically add users to groups based on their email addresses. This automatic assignment happens only at the time of account creation.

This can be set up in the Django admin interface (in the Accounts section).

Nota

The automatic group assignment for the Users and Viewers groups will always be created by Weblate upon migrations, in case you want to turn it off, simply set the regular expression to ^$, which will never match.

Users, roles, groups and permissions¶

The authentication models consist of several objects:

Permission: Individual permissions defined by Weblate. You can not assign individual permissions, this can only be done through assignment of roles.
Role: Role defines a set of permissions. This allows reuse of these sets in several places, and makes the administration easier.
User: Users can be members of several groups.
Group: Groups connect roles, users and authentication objects (projects, languages and component lists).

Permission checking¶

Whenever a permission is checked to decide whether one is able to perform a given action, the check is carried out according to scope, and the following checks are performed:

Project

Compared against the scope of the project, if not set, this matches no project.

You can use Project selection to automate inclusion of all projects.

Component list

The scope component is matched against this list, if not set, this is ignored.

Obviously this has no effect when checking access of the project scope, so you will have to grant access to view all projects in a component list by other means. By default this is achieved through the use of the Viewers group, see Default groups and roles).

Language

Compared against scope of translations, if not set, this matches no language.

You can use Language selection to automate inclusion of all languages.

Checking access to a project¶

A user has to be a member of a group linked to the project. Only membership is enough, no specific permissions are needed to access a project (this is used in the default Viewers group, see Default groups and roles).

Managing users and groups¶

All users and groups can be managed using the Django admin interface, available under /admin/ URL.

Managing per project access control¶

Nota

This feature only works for ACL controlled projects, see Per project access control.

Users with the Can manage ACL rules for a project privilege (see Access control) can also manage users in projects with access control turned on through the project page. You can add users, or remove them from a project, or make them owners of it.

The user management is available in the Tools menu of a project:

Ver también

Per project access control

Predefined groups¶

Weblate comes with a predefined set of groups for a project, wherefrom you can assign users.

Administration: Has all permissions available in the project.

Glossary: Can manage glossary (add or remove entries, or upload).

Languages: Can manage translated languages - add or remove translations.

Screenshots: Can manage screenshots - add or remove them, and associate them to source strings.

Template: Can edit translation templates in Monolingual components and source string info.

Translate: Can translate the project, and upload translations made offline.

VCS: Can manage VCS and access the exported repository.

Review: Can approve translations during review.

Billing: Can access billing info (see Billing).

Custom access control¶

By choosing Custom as Access control, Weblate will stop managing access for a given project, and you can set up custom rules in the Django admin interface. This can be used to define more complex access control, or set up a shared access policy for all projects in a single Weblate instance. If you want to enable this for all projects by default, please configure the DEFAULT_ACCESS_CONTROL.

Advertencia

By turning this on, Weblate will remove all Per project access control it has created for this project. If you are doing this without admin permission from the instance, you will instantly loose your access to manage the project.

Default groups and roles¶

List of privileges¶

Billing (see Billing): View billing info [Administration, Billing]
Changes: Download changes [Administration]
Comments: Post comment [Administration, Edit source, Power user, Review strings, Translate] Delete comment [Administration]
Component: Edit component settings [Administration] Lock component, preventing it from being translated [Administration]
Glossary: Add glossary entry [Administration, Manage glossary, Power user] Edit glossary entry [Administration, Manage glossary, Power user] Delete glossary entry [Administration, Manage glossary, Power user] Upload glossary entries [Administration, Manage glossary, Power user]
Machinery: Use machine translation services [Administration, Power user]
Projects: Edit project settings [Administration] Manage project access [Administration]
Reports: Download reports [Administration]
Screenshots: Add screenshot [Administration, Manage screenshots] Edit screenshot [Administration, Manage screenshots] Delete screenshot [Administration, Manage screenshots]
Source strings: Edit source string info [Administration, Edit source]
Strings: Add new strings [Administration] Ignore failing checks [Administration, Edit source, Power user, Review strings, Translate] Edit strings [Administration, Edit source, Power user, Review strings, Translate] Review strings [Administration, Review strings] Edit string when suggestions are enforced [Administration, Review strings] Edit source strings [Administration, Edit source, Power user]
Suggestions: Accept suggestions [Administration, Edit source, Power user, Review strings, Translate] Add suggestions [Add suggestion, Administration, Edit source, Power user, Review strings, Translate] Delete suggestions [Administration] Vote on suggestions [Administration, Edit source, Power user, Review strings, Translate]
Translations: Start new translation [Administration, Manage languages, Power user] Perform automatic translation [Administration, Manage languages] Delete existing translations [Administration, Manage languages] Start translation into a new language [Administration, Manage languages]
Uploads: Define author of translation upload [Administration] Overwrite existing strings with an upload [Administration, Edit source, Power user, Review strings, Translate] Upload translation strings [Administration, Edit source, Power user, Review strings, Translate]
VCS: Access the internal repository [Access repository, Administration, Manage repository, Power user] Commit changes to the internal repository [Administration, Manage repository] Push change from the internal repository [Administration, Manage repository] Reset changes in the internal repository [Administration, Manage repository] View upstream repository location [Access repository, Administration, Manage repository, Power user] Update the internal repository [Administration, Manage repository]

List of groups¶

The following groups are created upon installation (or after executing setupgroups):

Guests

Defines permissions for non authenticated users.

This group contains only anonymous users (see ANONYMOUS_USER_NAME).

You can remove roles from this group to limit permissions for non authenticated users.

Default roles: Add suggestion, Access repository

Viewers

This role ensures visibility of public projects for all users. By default all users are members of this group.

By default all users are members of this group, using Automatic group assignments.

Default roles: none

Users

Default group for all users.

By default all users are members of this group using Automatic group assignments.

Default roles: Power user

Reviewers

Group for reviewers (see Translation workflows).

Default roles: Review strings

Managers

Group for administrators.

Default roles: Administration

Advertencia

Never remove the predefined Weblate groups and users, this can lead to unexpected problems. If you do not want to use these features, just remove all privileges from them.

Translation projects¶

Translation organization¶

Weblate organizes translatable content into a tree-like structure. The bottom level object is Project configuration, which should hold all translations belonging together (for example translation of an application in several versions and/or accompanying documentation). On the level above, Component configuration, which is actually the component to translate. Here you define the VCS repository to use, and the mask of files to translate. Above Component configuration there are individual translations, handled automatically by Weblate as translation files (which match the mask defined in Component configuration) appear in the VCS repository.

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

Weblate supports a wide range of translation formats (both bilingual and monolingual ones) supported by Translate Toolkit, see Supported formats for more info.

Nota

You can share cloned VCS repositories using Weblate internal URLs. Using this feature is highly recommended when you have many components sharing the same VCS. It improves performance and decreases the required disk space.

Adding translation projects and components¶

Distinto en la versión 3.2: Since the 3.2 release the interface for adding projects and components is included in Weblate, and no longer requires you to use Django admin interface.

Distinto en la versión 3.4: As of 3.4, the process of adding components is multi staged, with automated discovery of most parameters.

Based on your permissions, you can create new translation projects and components in Weblate. It is always permitted for superusers, and if your instance uses billing (e.g. like https://hosted.weblate.org/ see Billing), you can also create those based on your plans allowance.

You can view your current billing plan on a separate page:

The project creation can be initiated from there, or using the menu in the navigation bar, filling in basic info about the translation project to complete addition of it:

After creating the project, you are taken directly to the project page:

Creating a new translation component can be initiated via a single click there. The process of creating a component is multi-staged and automatically detects most translation parameters.

First you need to fill in name and repository location:

On the next page, you are presented with a list of discovered translatable resources:

_images/user-add-component-discovery.png

As a last step, you review the translation component info and fill in optional details:

Ver también

Django admin interface, Project configuration, Component configuration

Project configuration¶

To add a new component for translation, you need to create a translation project first. The project is like a shelf, in which real translations are stacked. All components in the same project share suggestions and their dictionary; the translations are also automatically propagated through all components in a single project (unless turned off in the component configuration).

The project has only a few attributes that informs translators of it:

Project website: URL where translators can find more info about the project.
Mailing list: Mailing list where translators can discuss or comment translations.
Translation instructions: URL to more site with more detailed instructions for translators.
Set Translation-Team header: Whether Weblate should manage the Translation-Team header (this is a GNU Gettext only feature right now).
Use shared translation memory: Whether to use shared translation memory, see Shared translation memory for more details.
Access control: Configure per project access control, see Per project access control for more details.
Enable reviews: Enable review workflow, see Dedicated reviewers.
Enable hooks: Whether unauthenticated Notification hooks are to be used for this repository.
Source language: Language used for source strings in all components. Change this if you are translating from something else than English.

Nota

Most of the fields can be edited by project owners or managers, in the Weblate interface.

Adjusting interaction¶

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

Component configuration¶

A component is a grouping of something for translation. You enter a VCS repository location and file mask for which files you want translated, and Weblate automatically fetches from this VCS, and finds all matching translatable files.

You can find some examples of typical configurations in the Supported formats.

Nota

It is recommended to keep translation components to a reasonable size - split the translation by anything that makes sense in your case (individual apps or addons, book chapters or websites).

Weblate easily handles translations with 10000s of strings, but it is harder to split work and coordinate among translators with such large translation components.

Should the language definition for a translation be missing, an empty definition is created and named as «cs_CZ (generated)». You should adjust the definition and report this back to the Weblate authors, so that the missing languages can be included in next release.

The component contains all important parameters for working with the VCS, and for getting translations out of it:

Version control system

VCS to use, see Version control integration for details.

Source code repository

VCS repository used to pull changes, see Accessing repositories for more details.

This can either be a real VCS URL or weblate://project/component indicating that the repository should be shared with another component. See Weblate internal URLs for more details.

Repository push URL

Repository URL used for pushing. This is completely optional and push support is turned off when this is empty. See Accessing repositories for more details on how to specify a repository URL.

Repository browser

URL of repository browser used to display source files (location of used messages). When empty, no such links will be generated.

You can use the following format strings:

%(branchs)s - current branch
%(line)s - line in file
%(file)s - filename
%(../file)s - filename in parent directory
%(../../file)s - filename in grandparent directory

For example on GitHub, use something like https://github.com/WeblateOrg/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 a need to manually merge changes. You can use Git exporter to automate this for Git repositories.

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 (see Language definitions for info on how this is processed). In case your repository contains more than one translation file (e.g. more Gettext domains), you need to create a component for each of them.

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

In case your filename contains special chars such as [, ], these need to be escaped as [[] or []].

Monolingual base language file

Base file containing string definitions for Monolingual components.

Edit base file

Whether to allow editing the base file for Monolingual components.

Base file for new translations

Base file used to generate new translations, e.g. .pot file with Gettext, see Adding new translations for more info.

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 turn off 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 make use of a translation more than once.

It’s usually a good idea to turn this off for monolingual translations, unless you are using the same IDs across the whole project.

Save translation history

Whether to store a history of translation changes in the database.

Enable suggestions

Whether translation suggestions are accepted for this component.

Suggestion voting

Turns on votecasting for suggestions, see Suggestion voting.

Autoaccept suggestions

Automatically accept voted suggestions, see Suggestion voting.

Translation flags

Customization of quality checks and other Weblate behavior, see Customizing behavior.

Translation license

License of the translation, (does not need to be the same as the source code license).

License URL

URL where users can find the actual text of a license in full.

New language

How to handle requests for creation of new languages. Please note that the availability of choices depends on the file format, see Supported formats.

Merge style

You can configure how updates from the upstream repository are handled. This might not be supported for some VCSs. See Merge or rebase for more details.

Commit message

Message used when committing a translation, see Template markup.

Committer name

Name of the committer used for Weblate commits, the author will always be the real translator. On some VCSs this might be not supported. Default value can be changed by DEFAULT_COMMITER_NAME.

Committer email

Email of committer used for Weblate commits, the author will always be the real translator. On some VCSs this might be not supported. Default value can be changed by DEFAULT_COMMITER_EMAIL.

Push on commit

Whether committed changes should be automatically pushed to the upstream repository.

Age of changes to commit

Sets how old changes (in hours) are to get before they are committed by commit_pending management command (usually executed by Cron). The Default value can be changed by COMMIT_PENDING_HOURS.

Language filter

Regular expression used to filter the translation when scanning for file mask. This can be used to limit the list of languages managed by Weblate (e.g. ^(cs|de|es)$ will include only these languages. Please note that you need to list language codes as they appear in the filename.

Nota

Most of the fields can be edited by project owners or managers, in the Weblate interface.

Ver también

Does Weblate support other VCS than Git and Mercurial?, Translation component alerts

Template markup¶

Weblate uses simple markup language in several places where text rendering is needed. It is based on The Django template language, so it can be quite powerful.

Currently it is used in:

Commit message formatting, see Component configuration
Several addons

There following variables are available in the templates:

{{ language_code }}: Language code
{{ language_name }}: Language name
{{ component_name }}: Component name
{{ component_slug }}: Component slug
{{ project_name }}: Project name
{{ project_slug }}: Project slug
{{ url }}: Translation URL
{{ stats }}: Translation stats, this has further attributes, examples below.
{{ stats.all }}: Total strings count
{{ stats.fuzzy }}: Count of strings needing review
{{ stats.fuzzy_percent }}: Percent of strings needing review
{{ stats.translated }}: Translated strings count
{{ stats.translated_percent }}: Translated strings percent
{{ stats.allchecks }}: Number of strings with failing checks
{{ stats.allchecks_percent }}: Percent of strings with failing checks
{{ author }}: Author of current commit, available only in the commit scope.

You can combine them with filters:

{{ component|title }}

You can use conditions:

{% if stats.translated_percent > 80 %}Well translated!{% endif %}

There is additional tag available for replacing chars:

{% replace component "-" " " %}

You can combine it with filters:

{% replace component|capfirst "-" " " %}

…and other Django template features.

Importing speed¶

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

Optimize configuration¶

The default configuration is useful for testing and debugging Weblate, while for a production setup, you should do some adjustments. Many of them have quite a big impact on performance. Please check Production setup for more details, especially:

Check resource limits¶

If you are importing huge translations or repositories, you might be hit by resource limitations of your server.

Check the amount of free memory, having translation files cached by the operating system will greatly improve performance.
Disk operations might be bottleneck if there is a lot of strings to process - the disk is pushed by both Weblate and the database.
Additional CPU cores might help improve performance of background tasks (see Background tasks using Celery).

Disable unneeded checks¶

Some quality checks can be quite expensive, and if not needed, can save you some time during import if omitted. See CHECK_LIST for more info on how to configure this.

Automatic creation of components¶

In case your project has dozen of translation files (e.g. for different Gettext domains, or parts of Android apps), you might want to import them automatically. This can either be achieved from the command line by using import_project or import_json, or by installing the Component discovery addon.

To use the addon, you first need to create a component for one translation file (choose the one that is the least likely to be renamed or removed in future), and install the addon on this component.

For the management commands, you need to create a project which will contain all components and then run import_project or import_json.

Ver también

Management commands, Component discovery

Fulltext search¶

Fulltext search is based on Whoosh. It is processed in the background if Celery is set up. This leads to faster site response, and a less fragmented index with the added cost that it might be slightly outdated.

Ver también

Fulltext search is too slow, I get «Lock Error» quite often while translating, Rebuilding index has failed with «No space left on device»

Language definitions¶

In order to properly present different translations, Weblate needs to know some information about used languages. Currently it comes with definitions for about 200 languages and the definition includes language name, text direction, plural definitions and language code.

Parsing language codes¶

While parsing translations, Weblate attempts to map language code (usually the ISO 639-1 one) to existing language object. If it can not find exact match, it tries to find best fit in existing languages (eg. it ignores default country code for given language - choosing cs instead of cs_CZ). Should this fail as well, it will create new language definition using the defaults (left to right text direction, one plural) and naming the language :guilabel:xx_XX (generated). You might want to change this in the admin interface (see Changing language definitions) and report it to our issue tracker (see Contributing).

Changing language definitions¶

You can change language definitions in the admin interface (see Django admin interface). The Weblate languages section allows you to change or add language definitions. While editing, make sure that all fields are correct (especially plurals and text direction), otherwise the translators won’t be able to properly edit those translations.

Continuous translation¶

There is infrastructure in place so that your translation closely follows development. This way translators can work on translations the entire time, instead of working through huge amount of new text just prior to release.

This is the process:

Developers make changes and push them to the VCS repository.
Optionally the translation files are updated (this depends on the file format, see Why does Weblate still show old translation strings when I’ve updated the template?).
Weblate pulls changes from the VCS repository, see Updating repositories.
Once Weblate detects changes in translations, translators are notified based on their subscription settings.
Translators submit translations using the Weblate web interface, or upload offline changes.
Once the translators are finished, Weblate commits the changes to the local repository (see Lazy commits) and pushes them back if it has permissions to do so (see Pushing changes).

Updating repositories¶

You should set up some way of updating backend repositories from their source. Either use hooks (see Notification hooks) or just regularly run updategit (with selection of project or –all to update all).

Whenever Weblate updates the repository, the Post-update script hooks are executed.

With Gettext PO files, you might get bit by conflicts in PO file headers. To avoid it, you can use the shipped merge driver (examples/git-merge-gettext-po). Use it by putting the following configuration in your .gitconfig:

[merge "merge-gettext-po"]
  name = merge driver for Gettext PO files
  driver = /path/to/weblate/examples/git-merge-gettext-po %O %A %B

Then enable its use by defining proper attributes in the given repository (e.g. in .git/info/attributes):

*.po merge=merge-gettext-po

Nota

This merge driver assumes changes in POT files always are done in the attemptedly merged branch.

Distinto en la versión 2.9: This merge driver is now automatically installed for all Weblate internal repositories.

Avoiding merge conflicts¶

To avoid merge conflicts, control when translation files are updated in the upstream repository to avoid Weblate having changes on the same file.

You can achieve this using Weblate’s Web API to force Weblate to push all pending changes and lock the translation while you are doing changes on your side.

The script for doing updates can look like this:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

If you have multiple components sharing same repository, you need to lock them all separately:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Nota

The example uses Weblate Client, which needs configuration (API keys) to be able to control Weblate remotely. You can also achieve this using any HTTP client instead of wlc, e.g. curl, see Weblate’s Web API.

Automatically receiving changes from GitHub¶

Weblate comes with native support for GitHub.

If you are using Hosted Weblate, the recommended approach is to install the Hosted Weblate app, that way you will get the correct setup without having to set much up. It can also be used for pushing changes back.

To receive notifications on every push to a GitHub repository, add the Weblate Webhook in the repository settings (Webhooks) as shown on the image below:

For the payload URL, append /hooks/github/ to your Weblate URL, for example for the Hosted Weblate service, this is https://hosted.weblate.org/hooks/github/.

You can leave other values at default settings (Weblate can handle both content types and consumes just the push event).

Ver también

POST /hooks/github/, Pushing changes from Hosted Weblate

Automatically receiving changes from Bitbucket¶

Weblate has support for Bitbucket webhooks, add a webhook which triggers upon repository push, with destination to /hooks/bitbucket/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/bitbucket/).

Ver también

POST /hooks/bitbucket/, Pushing changes from Hosted Weblate

Automatically receiving changes from GitLab¶

Weblate has support for GitLab hooks, add a project webhook with destination to /hooks/gitlab/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/gitlab/).

Ver también

POST /hooks/gitlab/, Pushing changes from Hosted Weblate

Automatically receiving changes from Pagure¶

Nuevo en la versión 3.3.

Weblate has support for Pagure hooks, add a webhook with destination to /hooks/pagure/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/pagure/). This can be done in Activate Web-hooks under Project options:

Ver también

POST /hooks/pagure/, Pushing changes from Hosted Weblate

Automatically updating repositories nightly¶

Weblate automatically fetches remote repositories nightly to improve performance when merging changes later. You can optionally turn this into doing nightly merges as well, by enabling AUTO_UPDATE.

Pushing changes¶

Each project can have a push URL set up, and in that case Weblate offers a button in the web interface to push changes to the remote repository. Weblate can be also be configured to automatically push changes on every commit.

If you are using SSH to push, you will need to have a key without a passphrase (or use ssh-agent for Django), and the remote server needs to be verified by you via the admin interface first, otherwise pushing will fail.

The push options differ based on the Version control integration used, more details are found in that chapter.

Nota

You can also enable automatic pushing of changes on commits, this can be done in Component configuration.

Ver también

See Accessing repositories for setting up SSH keys, and Lazy commits for info about when Weblate decides to commit changes.

Pushing changes from Hosted Weblate¶

For Hosted Weblate there is a dedicated push user registered on GitHub, Bitbucket and GitLab (with username weblate named Weblate push user). You need to add this user as a collaborator and give it permission to push to your repository. Let us know when you’ve done so and we will enable pushing changes from Hosted Weblate for you.

Merge or rebase¶

By default, Weblate merges the upstream repository into its own. This is the safest way in case you also access the underlying repository by other means. In case you don’t need this, you can enable rebasing of changes on upstream, which will produce history with fewer merge commits.

Nota

Rebasing can cause you trouble in case of complicated merges, so carefully consider whether or not you want to enable them.

Interacting with others¶

Weblate makes it easy to interact with others using its API.

Ver también

Weblate’s Web API

Lazy commits¶

The behaviour of Weblate is to group commits from the same author into one commit if possible. This greatly reduces the number of commits, however you might need to explicitly tell it to do the commits in case you want to get the VCS repository in sync, e.g. for merge (this is by default allowed for the Managers group, see Access control).

The changes in this mode are committed once any of the following conditions are fulfilled:

Somebody else changes an already changed string.
A merge from upstream occurs.
An explicit commit is requested.
Change is older than period defined as Age of changes to commit on Component configuration.

If you want to commit changes more frequently and without checking of age, you can schedule a regular task to perform a commit:

CELERY_BEAT_SCHEDULE = {
    # Unconditionally commit all changes every 2 minutes
    'commit': {
        'task': 'weblate.trans.tasks.commit_pending',
        # Ommiting hours will honor per component settings,
        # otherwise components with no changes older than this
        # won't be committed
        'kwargs': {'hours': 0},
        # How frequently to execute the job in seconds
        'schedule': 120,
    }
}

Processing repository with scripts¶

The way to customize how Weblate interacts with the repository is Addons. Consult Executing scripts from addon for info on how to execute external scripts through addons.

Licensing translations¶

Weblate allows you to specify under which license the translations are contributed. This is especially important to specify if the translations are open to the public to raise proper expectations what can be done with the translations.

There are two things you specify on the Component configuration - license information and the contributor agreement.

License information¶

Upon specifying license information (license name and URL), this information is shown in the translation information, but it is not enforced in any way.

Usually this is best location to place information on licensing where no explicit consent is required.

Contributor agreement¶

Once you specify contributor agreement, only users who have agreed to it will be able to contribute. This is clearly visible when accessing the translation:

The entered text is formatted into paragraphs and external links are possible. HTML markup can not be used.

Signed off by¶

Should your project require Signed-off-by header in the commits, you should enable contributor agreement with the DCO text and add the header to the commit message (see Template markup for more details). The full commit message can look like:

Translated using Weblate ({{ language_name }})

Currently translated at {{ stats.translated_percent }}% ({{ stats.translated }} of {{ stats.all }} strings)

Translation: {{ project_name }}/{{ component_name }}
Translate-URL: {{ url }}
Signed-off-by: {{ author }}

User licenses¶

User can review licenses on projects he is contributing to in the profile:

Translation process¶

Suggestion voting¶

Nuevo en la versión 1.6: This feature is available since Weblate 1.6.

By default, everyone can add suggestions, which logged in users can accept. Requiring more then one person for acceptance can be achieved by suggestion voting. You can enable this on Component configuration configuration by Suggestion voting and Autoaccept suggestions. The first one enables the voting feature, while the latter sets the threshold a suggestion is automatically is accepted (this includes a vote from the user making the suggestion).

Nota

Once automatic acceptance is set up, normal users lose the privilege to directly save translations or accept suggestions. This can be overridden by Can override suggestion state privilege (see Access control).

You can combine these with Access control into one of the following setups:

Users suggest and vote for suggestions, a limited group controls what is accepted - turn on voting, but automatic acceptance off, and don’t let users save translations.
Users suggest and vote for suggestions with automatical acceptance once the defined number of them agree - turn on voting and set the desired number of votes for automatic acceptance.
Optional voting for suggestions - you can also turn on voting only, and in this case it can optionally be used by users when they are unsure about a translation by making multiple suggestions.

Additional info on source strings¶

Enhance the translation process with info available in the translation files. This includes string prioritization, check flags, or providing visual context. All these features can be set on the Reviewing source strings:

Access this directly from the translating interface by clicking the «Edit» icon next to Screenshot context, Flags or String priority:

Strings prioritization¶

Nuevo en la versión 2.0.

You can change string priority, strings with higher priority are offered first for translation. This can be useful for prioritizing translation of strings which are seen first by users or are otherwise important.

Translation flags¶

Nuevo en la versión 2.4.

Distinto en la versión 3.3: Previously this was called Quality checks flags, but as it no longer configures only checks, the name was changed to be more generic.

The default set of translation flags is determined by the translation Component configuration and the translation file. However, you might want to use it to customize this per source string.

Ver también

Quality checks

Visual context for strings¶

Nuevo en la versión 2.9.

You can upload a screenshot showing a given source string in use within your program. This helps translators understand where it is used, and how it should be translated.

The uploaded screenshot is shown in the translation context sidebar:

In addition to Reviewing source strings, screenshots have a separate management interface under Tools menu. Upload screenshots, assign them to source strings manually or with the use of OCR.

Once a screenshot is uploaded, this interface handles management and assigning it to source strings:

Checks and fixups¶

Custom automatic fixups¶

You can also implement your own automatic fixup in addition to the standard ones and include them in AUTOFIX_LIST.

The automatic fixes are powerful, but can also cause damage; be careful when writing one.

For example, the following automatic fixup would replace every occurrence of string foo in translation with bar:

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#

from weblate.trans.autofixes.base import AutoFix
from django.utils.translation import ugettext_lazy as _


class ReplaceFooWithBar(AutoFix):
    """Replace foo with bar."""

    name = _('Foobar')

    def fix_single_target(self, target, source, unit):
        if 'foo' in target:
            return target.replace('foo', 'bar'), True
        return target, False

To install custom checks, you need to provide a fully-qualified path to the Python class in the AUTOFIX_LIST, see Using custom modules and classes.

Customizing behavior¶

You can fine tune Weblate behavior (mostly checks) for each source string (in source strings review, see Additional info on source strings) or in the Component configuration (Translation flags); here is a list of flags currently accepted:

rst-text: Treat text as RST document, effects Unchanged translation.
dos-eol: Use DOS end of line markers instead of Unix ones (\r\n instead of \n).
max-length:N: Limit maximal length for string to N chars, see Maximum Length
xml-text: Treat text as XML document, affects Invalid XML markup and XML tags mismatch.
python-format, c-format, php-format, python-brace-format, javascript-format, c-sharp-format, java-format, java-messageformat, auto-java-messageformat: Treats all strings like format strings, affects Formatted strings, Formatted strings, Formatted strings, Formatted strings, Formatted strings, Formatted strings, Formatted strings, Formatted strings, Unchanged translation.
ignore-end-space: Skip the «Trailing space» quality check.
ignore-inconsistent: Skip the «Inconsistent» quality check.
ignore-translated: Skip the «Has been translated» quality check.
ignore-begin-newline: Skip the «Starting newline» quality check.
ignore-zero-width-space: Skip the «Zero-width space» quality check.
ignore-escaped-newline: Skip the «Mismatched n» quality check.
ignore-same: Skip the «Unchanged translation» quality check.
ignore-end-question: Skip the «Trailing question» quality check.
ignore-end-ellipsis: Skip the «Trailing ellipsis» quality check.
ignore-ellipsis: Skip the «Ellipsis» quality check.
ignore-python-brace-format: Skip the «Python brace format» quality check.
ignore-end-newline: Skip the «Trailing newline» quality check.
ignore-c-format: Skip the «C format» quality check.
ignore-javascript-format: Skip the «Javascript format» quality check.
ignore-optional-plural: Skip the «Optional plural» quality check.
ignore-end-exclamation: Skip the «Trailing exclamation» quality check.
ignore-end-colon: Skip the «Trailing colon» quality check.
ignore-xml-invalid: Skip the «Invalid XML markup» quality check.
ignore-xml-tags: Skip the «XML tags mismatch» quality check.
ignore-python-format: Skip the «Python format» quality check.
ignore-plurals: Skip the «Missing plurals» quality check.
ignore-begin-space: Skip the «Starting spaces» quality check.
ignore-bbcode: Skip the «Mismatched BBcode» quality check.
ignore-multiple-failures: Skip the «Multiple failing checks» quality check.
ignore-php-format: Skip the «PHP format» quality check.
ignore-end-stop: Skip the «Trailing stop» quality check.
ignore-angularjs-format: Skip the «AngularJS interpolation string» quality check.
ignore-c-sharp-format: Skip the «C# format» quality check.
ignore-java-format: Skip the «Java format» quality check.

Nota

Generally the rule is named ignore-* for any check, using its identifier, so you can use this even for your custom checks.

These flags are understood both in Component configuration settings, per source string settings and in translation file itself (eg. in GNU Gettext).

Writing own checks¶

Weblate comes with wide range of quality checks (see Quality checks), though they might not 100% cover all you want to check. The list of performed checks can be adjusted using CHECK_LIST and you can also add custom checks. All you need to do is to subclass weblate.checks.Check, set few attributes and implement either check or check_single methods (first one if you want to deal with plurals in your code, the latter one does this for you). You will find below some examples.

To install custom checks, you need to provide a fully-qualified path to the Python class in the CHECK_LIST, see Using custom modules and classes.

Checking translation text does not contain «foo»¶

This is a pretty simple check which just checks whether translation does not contain string «foo».

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#
"""Simple quality check example."""

from weblate.checks.base import TargetCheck
from django.utils.translation import ugettext_lazy as _


class FooCheck(TargetCheck):

    # Used as identifier for check, should be unique
    # Has to be shorter than 50 chars
    check_id = 'foo'

    # Short name used to display failing check
    name = _('Foo check')

    # Description for failing check
    description = _('Your translation is foo')

    # Real check code
    def check_single(self, source, target, unit):
        return 'foo' in target

Checking Czech translation text plurals differ¶

Check using language information to verify that two plural forms in Czech language are not same.

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#
"""Quality check example for Czech plurals."""

from weblate.checks.base import TargetCheck
from django.utils.translation import ugettext_lazy as _


class PluralCzechCheck(TargetCheck):

    # Used as identifier for check, should be unique
    # Has to be shorter than 50 chars
    check_id = 'foo'

    # Short name used to display failing check
    name = _('Foo check')

    # Description for failing check
    description = _('Your translation is foo')

    # Real check code
    def check_target_unit(self, sources, targets, unit):
        if self.is_language(unit, ('cs', )):
            return targets[1] == targets[2]
        return False

    def check_single(self, source, target, unit):
        """We don't check target strings here."""
        return False

Using custom modules and classes¶

You have implemented code for Custom automatic fixups or Customizing behavior and now it’s time to install it into Weblate. That can be achieved by adding its fully-qualified path to Python class to appropriate settings.

This means that the module with class needs to be placed somewhere where the Python interpreter can import it - either in system path (usually something like /usr/lib/python2.7/site-packages/) or in Weblate directory, which is also added to the interpreter search path.

Assuming you’ve created mahongo.py containing your custom quality check, you can place it among Weblate checks in weblate/trans/checks/ folder and then add it as following:

CHECK_LIST = (
    'weblate.checks.mahongo.MahongoCheck',
)

As you can see, it’s a comma-separated path to your module and class name.

Alternatively, you can create a proper Python package out of your customization:

Place your Python module with check into folder which will match your package name. We’re using weblate_custom_checks in following examples.
Add empty __init__.py file to the same directory. This ensures Python can import this whole package.

Write setup.py in parent directory to describe your package:

from setuptools import setup

setup(
    name = "weblate_custom_checks",
    version = "0.0.1",
    author = "Michal Cihar",
    author_email = "michal@cihar.com",
    description = "Sample Custom check for Weblate.",
    license = "BSD",
    keywords = "weblate check example",
    packages=['weblate_custom_checks'],
)

Now you can install it using python setup.py install

Once installed into system Python path, you can use it from there:

CHECK_LIST = (
    'weblate_custom_checks.mahongo.MahongoCheck',
)

Overall your module structure should look like:

weblate_custom_checks
├── setup.py
└── weblate_custom_checks
    ├── __init__.py
    └── mahongo.py

Machine translation¶

Weblate has built in support for several machine translation services and it’s up to the administrator to enable them. The services have different terms of use, so please check whether you are allowed to use them before enabling them in Weblate. The individual services are enabled using MT_SERVICES.

The source language can be configured at Project configuration.

Amagama¶

Special installation of tmserver run by Virtaal authors.

To enable this service, add weblate.machinery.tmserver.AmagamaTranslation to MT_SERVICES.

Ver también

Amagama, Amagama Translation Memory

Apertium¶

A free/open-source machine translation platform providing translation to a limited set of languages.

The recommended way to use Apertium is to run your own Apertium APy server.

To enable this service, add weblate.machinery.apertium.ApertiumAPYTranslation to MT_SERVICES and set MT_APERTIUM_APY.

Ver también

MT_APERTIUM_APY, Apertium website, Apertium APy documentation

AWS¶

Nuevo en la versión 3.1.

Amazon Translate is a neural machine translation service for translating text to and from English across a breadth of supported languages.

To enable this service, add weblate.machinery.aws.AWSTranslation to MT_SERVICES, install the boto3 module and set the settings.

Ver también

MT_AWS_REGION, MT_AWS_ACCESS_KEY_ID, MT_AWS_SECRET_ACCESS_KEY Amazon Translate Documentation

Baidu API machine translation¶

Nuevo en la versión 3.2.

Machine translation service provided by Baidu.

This service uses an API and you need to obtain ID and API key from Baidu.

To enable this service, add weblate.machinery.baidu.BaiduTranslation to MT_SERVICES and set MT_BAIDU_ID and MT_BAIDU_SECRET.

Ver también

MT_BAIDU_ID, MT_BAIDU_SECRET Baidu Translate API

DeepL¶

Nuevo en la versión 2.20.

DeepL is paid service providing good machine translation for few languages. According to some benchmark it’s currently best available service.

To enable this service, add weblate.machinery.deepl.DeepLTranslation to MT_SERVICES and set MT_DEEPL_KEY.

Ver también

MT_DEEPL_KEY, DeepL website, DeepL API documentation

Glosbe¶

Free dictionary and translation memory for almost every living language.

API is free to use, but subject to the used data source license. There is a limit of calls that may be done from one IP in fixed period of time, to prevent abuse.

To enable this service, add weblate.machinery.glosbe.GlosbeTranslation to MT_SERVICES.

Ver también

Glosbe website

Google Translate¶

Machine translation service provided by Google.

This service uses Translation API and you need to obtain an API key and enable billing on Google API console.

To enable this service, add weblate.machinery.google.GoogleTranslation to MT_SERVICES and set MT_GOOGLE_KEY.

Ver también

MT_GOOGLE_KEY, Google translate documentation

Microsoft Cognitive Services Translator¶

Nuevo en la versión 2.10.

Nota

This is replacement service for Microsoft Translator.

Machine translation service provided by Microsoft in Azure portal as a one of Cognitive Services.

You need to register at Azure portal and use the key you obtain there.

To enable this service, add weblate.machinery.microsoft.MicrosoftCognitiveTranslation to MT_SERVICES and set MT_MICROSOFT_COGNITIVE_KEY.

Ver también

MT_MICROSOFT_COGNITIVE_KEY, Cognitive Services - Text Translation API, Microsoft Azure Portal

Microsoft Terminology Service¶

Nuevo en la versión 2.19.

The Microsoft Terminology Service API allows you to programmatically access the terminology, definitions and user interface (UI) strings available on the Language Portal through a web service.

To enable this service, add weblate.machinery.microsoftterminology.MicrosoftTerminologyService to MT_SERVICES.

Ver también

Microsoft Terminology Service API

MyMemory¶

Huge translation memory with machine translation.

Free, anonymous usage is currently limited to 100 requests/day, or to 1000 requests/day when you provide contact email in MT_MYMEMORY_EMAIL. You can also ask them for more.

To enable this service, add weblate.machinery.mymemory.MyMemoryTranslation to MT_SERVICES and set MT_MYMEMORY_EMAIL.

Ver también

MT_MYMEMORY_EMAIL, MT_MYMEMORY_USER, MT_MYMEMORY_KEY, MyMemory website

Netease Sight API machine translation¶

Nuevo en la versión 3.3.

Machine translation service provided by Netease.

This service uses an API and you need to obtain key and secret from Netease.

To enable this service, add weblate.machinery.youdao.NeteaseSightTranslation to MT_SERVICES and set MT_NETEASE_KEY and MT_NETEASE_SECRET.

Ver también

MT_NETEASE_KEY, MT_NETEASE_SECRET Netease Sight Translation Platform

tmserver¶

You can run your own translation memory server which is bundled with Translate-toolkit and let Weblate talk to it. You can also use it with amaGama server, which is an enhanced version of tmserver.

First you will want to import some data to the translation memory:

To enable this service, add weblate.machinery.tmserver.TMServerTranslation to MT_SERVICES.

build_tmdb -d /var/lib/tm/db -s en -t cs locale/cs/LC_MESSAGES/django.po
build_tmdb -d /var/lib/tm/db -s en -t de locale/de/LC_MESSAGES/django.po
build_tmdb -d /var/lib/tm/db -s en -t fr locale/fr/LC_MESSAGES/django.po

Now you can start tmserver to listen to your requests:

tmserver -d /var/lib/tm/db

And configure Weblate to talk to it:

MT_TMSERVER = 'http://localhost:8888/tmserver/'

Ver también

MT_TMSERVER, tmserver Amagama, Amagama Translation Memory

Yandex Translate¶

Machine translation service provided by Yandex.

This service uses Translation API and you need to obtain API key from Yandex.

To enable this service, add weblate.machinery.yandex.YandexTranslation to MT_SERVICES and set MT_YANDEX_KEY.

Ver también

MT_YANDEX_KEY, Yandex Translate API, Powered by Yandex.Translate

Youdao Zhiyun API machine translation¶

Nuevo en la versión 3.2.

Machine translation service provided by Youdao.

This service uses an API and you need to obtain ID and API key from Youdao.

To enable this service, add weblate.machinery.youdao.YoudaoTranslation to MT_SERVICES and set MT_YOUDAO_ID and MT_YOUDAO_SECRET.

Ver también

MT_YOUDAO_ID, MT_YOUDAO_SECRET Youdao Zhiyun Natural Language Translation Service

Weblate¶

Weblate can be source of machine translation as well. It is based on the fulltext engine Whoosh and provides both exact and inexact matches.

To enable these services, add weblate.machinery.weblatetm.WeblateTranslation to MT_SERVICES.

Weblate Translation Memory¶

Nuevo en la versión 2.20.

The Translation Memory can be used as source for machine translation suggestions as well.

To enable these services, add weblate.memory.machine.WeblateMemory to the MT_SERVICES. This service is enabled by default.

SAP Translation Hub¶

Machine translation service provided by SAP.

You need to have a SAP account (and enabled the SAP Translation Hub in the SAP Cloud Platform) to use this service.

To enable this service, add weblate.machinery.saptranslationhub.SAPTranslationHub to MT_SERVICES and set appropriate access to either sandbox or productive API.

Nota

To access the Sandbox API, you need to set MT_SAP_BASE_URL and MT_SAP_SANDBOX_APIKEY.

To access the productive API, you need to set MT_SAP_BASE_URL, MT_SAP_USERNAME and MT_SAP_PASSWORD.

Ver también

MT_SAP_BASE_URL, MT_SAP_SANDBOX_APIKEY, MT_SAP_USERNAME, MT_SAP_PASSWORD, MT_SAP_USE_MT SAP Translation Hub API

Custom machine translation¶

You can also implement your own machine translation services using a few lines of Python code. This example implements translation to a fixed list of languages using dictionary Python module:

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#
"""Machine translation example."""

from weblate.machinery.base import MachineTranslation
import dictionary


class SampleTranslation(MachineTranslation):
    """Sample machine translation interface."""
    name = 'Sample'

    def download_languages(self):
        """Return list of languages your machine translation supports."""
        return set(('cs',))

    def download_translations(self, source, language, text, unit, user):
        """Return tuple with translations."""
        return [(t, 100, self.name, text) for t in dictionary.translate(text)]

You can list own class in MT_SERVICES and Weblate will start using that.

Addons¶

Nuevo en la versión 2.19.

Addons provide ways to customize translation workflow. You can install addons to your translation component and they will work behind the scenes. The addon management can be found under Manage menu of a translation component.

Built in addons¶

Cleanup translation files¶

Update all translation files to match the monolingual base file. For most file formats, this means removing stale translation keys no longer present in the base file.

Language consistency¶

This addon ensures that all components within one project have translation to same languages.

Unlike most others, this addon operates on whole project.

Component discovery¶

This addon automatically adds or removes components to the project based on file changes in the version control system.

It is similar to the import_project management command, but the major difference is that it is triggered on every VCS update. This way you can easily track multiple translation components within one VCS.

To use component discovery, you first need to create one component which will act as master and others will use Weblate internal URLs to it as a VCS configuration. You should choose the one which is less likely to disappear in the future here.

Once you have one component from the target VCS, you can configure the discovery addon to find all translation components in the VCS. The matching is done using regular expression so it can be quite powerful, but it can be complex to configure. You can use examples in the addon help for some common use cases.

Once you hit save, you will be presented with a preview of matched components, so you can check whether the configuration actually matches your needs:

Ver también

Template markup

Flag unchanged translations to need edit¶

Nuevo en la versión 3.1.

Whenever a new translation string is imported from the VCS and it matches source strings, it is flagged as needing editing in Weblate. This is especially useful for file formats including all strings even if they are not translated.

Flag new source strings to need edit¶

Whenever a new source string is imported from the VCS, it is flagged as needing editing in Weblate. This way you can easily filter and edit source strings written by the developers.

Flag new translations to need edit¶

Whenever a new translation string is imported from the VCS, it is flagged as needing editing in Weblate. This way you can easily filter and edit translations created by the developers.

Statistics generator¶

This addon generates a file containing detailed information about the translation. You can use Django template in both filename and content, see Template markup for detailed markup description.

For example generating summary file for each translations:

Name of generated file

locale/{{ language_code }}.json

Content

{
   "language": "{{ language_code }}",
   "strings": "{{ stats.all }}",
   "translated": "{{ stats.translated }}",
   "last_changed": "{{ stats.last_changed }}",
   "last_author": "{{ stats.last_author }}",
}

Ver también

Template markup

Contributors in comment¶

Update comment in the PO file header to include contributor name and years of contributions.

Update ALL_LINGUAS variable in the configure file¶

Updates the ALL_LINGUAS variable in configure, configure.in or configure.ac files, when a new translation is added.

Customize gettext output¶

Allows customization of gettext output behavior, for example line wrapping.

Update LINGUAS file¶

Updates the LINGUAS file when a new translation is added.

Generate MO files¶

Automatically generates MO file for every changed PO file.

Update PO files to match POT (msgmerge)¶

Update all PO files to match the POT file using msgmerge. This is triggered whenever new changes are pulled from the upstream repository.

Squash Git commits¶

Squash Git commits prior to pushing changes.

Customize JSON output¶

Allows to customize JSON output behavior, for example indentation or sorting.

Formats the Java properties file¶

This addon sorts the Java properties file.

Customizing list of addons¶

List of addons is configured by WEBLATE_ADDONS, to add another addon simply include class absolute name in this setting.

Writing addon¶

You can write own addons as well, all you need to do is subclass BaseAddon, define addon metadata and implement callback which will do the processing.

You can look at example addon for more information:

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#

from __future__ import unicode_literals

from django.utils.translation import ugettext_lazy as _

from weblate.addons.base import BaseAddon
from weblate.addons.events import EVENT_PRE_COMMIT


class ExampleAddon(BaseAddon):
    # Filter for compatible components, every key is
    # matched against property of component
    compat = {
        'file_format': frozenset((
            'po', 'po-mono',
        )),
    }
    # List of events addon should receive
    events = (EVENT_PRE_COMMIT,)
    # Addon unique identifier
    name = 'weblate.example.example'
    # Verbose name shown in the user interface
    verbose = _('Example addon')
    # Detailed addon description
    description = _('This addon does nothing it is just an example.')

    # Callback to implement custom behavior
    def pre_commit(self, translation, author):
        return

Executing scripts from addon¶

You can also use addons to execute external scripts. This used to be integrated in Weblate, but now you have to write little code to wrap your script with an addon.

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#
"""
Example pre commit script
"""

from __future__ import unicode_literals

from django.utils.translation import ugettext_lazy as _

from weblate.addons.events import EVENT_PRE_COMMIT
from weblate.addons.scripts import BaseScriptAddon


class ExamplePreAddon(BaseScriptAddon):
    # Event used to trigger the script
    events = (EVENT_PRE_COMMIT,)
    # Name of the addon, has to be unique
    name = 'weblate.example.pre'
    # Verbose name and long descrption
    verbose = _('Execute script before commit')
    description = _('This addon executes a script.')

    # Script to execute
    script = '/bin/true'
    # File to add in commit (for pre commit event)
    # does not have to be set
    add_file = 'po/{{ language_code }}.po'

The script is executed with the current directory set to the root of the VCS repository for given component.

Additionally, the following environment variables are available:

WL_VCS¶: Version control system used.

WL_REPO¶: Upstream repository URL.

WL_PATH¶: Absolute path to VCS repository.

WL_BRANCH¶: Nuevo en la versión 2.11.

Repository branch configured in the current component.

WL_FILEMASK¶: File mask for current component.

WL_TEMPLATE¶: File name of template for monolingual translations (can be empty).

WL_NEW_BASE¶: Nuevo en la versión 2.14.

File name of the file which is used for creating new translations (can be empty).

WL_FILE_FORMAT¶: File format used in current component.

WL_LANGUAGE¶: Language of currently processed translation (not available for component level hooks).

WL_PREVIOUS_HEAD¶: Previous HEAD on update (available only available when running post update hook).

Ver también

Component configuration

Post update repository processing¶

Post update repository processing can be used to update translation files on the source change. To achieve this, please remember that Weblate only sees files which are committed to the VCS, so you need to commit changes as a part of the script.

For example with gulp you can do it using following code:

#! /bin/sh
gulp --gulpfile gulp-i18n-extract.js
git commit -m 'Update source strings' src/languages/en.lang.json

Pre commit processing of translations¶

In many cases you might want to automatically do some changes to the translation before it is committed to the repository. The pre commit script is exactly the place to achieve this.

It is passed a single parameter consisting of file name of current translation.

Translation Memory¶

Nuevo en la versión 2.20.

Weblate comes with a built-in translation memory. It provides you matches against it as a Machine translation or in Automatic translation.

Nota

Currently the content of the translation memory is not updated by Weblate itself, but you can use it to import your existing TMX files and let Weblate provide these as a machine translations. This will be changed in future release to provide full translation memory experience within Weblate.

For installation tips, see Weblate Translation Memory, however this service is enabled by default.

Translation memory scopes¶

Nuevo en la versión 3.2: The different translation memory scopes are available since Weblate 3.2, prior to this release translation memory could be only loaded from file corresponding to the current imported translation memory scope.

The translation memory scopes are there to allow both privacy and sharing of translations, depending on the actual desired behavior.

Imported translation memory¶

You can import arbitrary translation memory data using import_memory command. The memory content will be available for all users and projects.

Per user translation memory¶

All user translations are automatically stored in personal translation memory. This memory is available only for this user.

Per project translation memory¶

All translations within a project are automatically stored in a project translation memory. This memory is available only for this project.

Shared translation memory¶

All translation within projects which have enabled shared translation memory are stored in shared translation memory. This shared memory is available for all projects then.

Please consider carefully when enabling this feature on shared Weblate installations as this might have severe implications:

The translations can be used by anybody else.
This might lead to disclosing secret information.

Managing translation memory¶

User interface¶

Nuevo en la versión 3.2.

There is basic user interface to manage per user and per project translation memories. It can be used to download, wipe or import it.

The downloads in JSON are useful for Weblate, TMX is provided for interoperability with other tools.

Management interface¶

There are several management commands to manipulate with the translation memory content, these operate on memory as whole not filtered by scopes (unless requested by parameters):

dump_memory: Exporting the memory into JSON
import_memory: Importing TMX or JSON files into the memory
list_memory: Listing memory content
delete_memory: Deleting content from the memory

Configuration¶

All settings are stored in settings.py (as usual for Django).

Nota

After changing any of these settings, you need to restart Weblate. In case it is run as mod_wsgi, you need to restart Apache to reload the configuration.

Ver también

Please also check Django’s documentation for parameters which configure Django itself.

AKISMET_API_KEY¶

Weblate can use Akismet to check incoming anonymous suggestions for spam. Visit akismet.com to purchase an API key and associate it with a site.

ANONYMOUS_USER_NAME¶

User name of user for defining privileges of not logged in user.

Ver también

Access control

AUTH_LOCK_ATTEMPTS¶

Nuevo en la versión 2.14.

Maximum number of failed authentication attempts before rate limiting is applied.

This is currently applied in the following locations:

On login, the account password is reset. User will not be able to log in after that using password until he asks for password reset.
On password reset, the reset mails are no longer sent. This avoids spamming user with too many password reset attempts.

Defaults to 10.

Ver también

Rate limiting,

AUTO_UPDATE¶

Nuevo en la versión 3.2.

Automatically update all repositories on daily basis. This can be useful if you do not use Notification hooks to update Weblate repositories automatically.

Nota

This requires Background tasks using Celery working and you will have to restart celery for this setting to take effect.

AVATAR_URL_PREFIX¶

Prefix for constructing avatar URLs. The URL will be constructed like: ${AVATAR_URL_PREFIX}/avatar/${MAIL_HASH}?${PARAMS}. Following services are known to work:

Gravatar (default), see https://gravatar.com/: AVATAR_URL_PREFIX = 'https://www.gravatar.com/'
Libravatar, see https://www.libravatar.org/: AVATAR_URL_PREFIX = 'https://seccdn.libravatar.org/'

Ver también

Avatar caching, ENABLE_AVATARS, Avatars

RATELIMIT_ATTEMPTS¶

Nuevo en la versión 3.2.

Maximum number of authentication attempts before rate limiting applies.

Defaults to 5.

Ver también

Rate limiting, RATELIMIT_WINDOW, RATELIMIT_LOCKOUT

RATELIMIT_WINDOW¶

Nuevo en la versión 3.2.

Length of authentication window for rate limiting in seconds.

Defaults to 300 (5 minutes).

Ver también

Rate limiting, RATELIMIT_ATTEMPTS, RATELIMIT_LOCKOUT

RATELIMIT_LOCKOUT¶

Nuevo en la versión 3.2.

Length of authentication lockout window after rate limit is applied.

Defaults to 600 (10 minutes).

Ver también

Rate limiting, RATELIMIT_ATTEMPTS, RATELIMIT_WINDOW

AUTH_TOKEN_VALID¶

Nuevo en la versión 2.14.

Validity of token in activation and password reset mails in seconds.

Defaults to 3600 (1 hour).

AUTH_PASSWORD_DAYS¶

Nuevo en la versión 2.15.

Define (in days) how long in past Weblate should reject reusing same password.

Nota

Password changes done prior to Weblate 2.15 will not be accounted for this policy, it is valid only

Defaults to 180 days.

AUTOFIX_LIST¶

List of automatic fixups to apply when saving the message.

You need to provide a fully-qualified path to the Python class implementing the autofixer interface.

Available fixes:

weblate.trans.autofixes.whitespace.SameBookendingWhitespace: Fixes up whitespace in beginning and end of the string to match source.
weblate.trans.autofixes.chars.ReplaceTrailingDotsWithEllipsis: Replaces trailing dots with ellipsis if source string has it.
weblate.trans.autofixes.chars.RemoveZeroSpace: Removes zero width space char if source does not contain it.
weblate.trans.autofixes.chars.RemoveControlCharS: Removes control characters if source does not contain it.

For example you can enable only few of them:

AUTOFIX_LIST = (
    'weblate.trans.autofixes.whitespace.SameBookendingWhitespace',
    'weblate.trans.autofixes.chars.ReplaceTrailingDotsWithEllipsis',
)

Ver también

Automatic fixups, Custom automatic fixups

BASE_DIR¶

Base directory where Weblate sources are located. This is used to derive several other paths by default:

DATA_DIR
TTF_PATH

Default value: Top level directory of Weblate sources.

CHECK_LIST¶

List of quality checks to perform on translation.

You need to provide a fully-qualified path to the Python class implementing the check interface.

Some of the checks are not useful for all projects, so you are welcome to adjust the list list of checks to be performed on your installation.

For example you can enable only few of them:

CHECK_LIST = (
    'weblate.checks.same.SameCheck',
    'weblate.checks.chars.BeginNewlineCheck',
    'weblate.checks.chars.EndNewlineCheck',
    'weblate.checks.chars.BeginSpaceCheck',
    'weblate.checks.chars.EndSpaceCheck',
    'weblate.checks.chars.EndStopCheck',
    'weblate.checks.chars.EndColonCheck',
    'weblate.checks.chars.EndQuestionCheck',
    'weblate.checks.chars.EndExclamationCheck',
    'weblate.checks.chars.EndEllipsisCheck',
    'weblate.checks.chars.EndSemicolonCheck',
    'weblate.checks.chars.MaxLengthCheck',
    'weblate.checks.format.PythonFormatCheck',
    'weblate.checks.format.PythonBraceFormatCheck',
    'weblate.checks.format.PHPFormatCheck',
    'weblate.checks.format.CFormatCheck',
    'weblate.checks.format.PerlFormatCheck',
    'weblate.checks.format.JavascriptFormatCheck',
    'weblate.checks.format.CSharpFormatCheck',
    'weblate.checks.format.JavaFormatCheck',
    'weblate.checks.consistency.SamePluralsCheck',
    'weblate.checks.consistency.PluralsCheck',
    'weblate.checks.consistency.ConsistencyCheck',
    'weblate.checks.consistency.TranslatedCheck',
    'weblate.checks.chars.NewlineCountingCheck',
    'weblate.checks.markup.BBCodeCheck',
    'weblate.checks.chars.ZeroWidthSpaceCheck',
    'weblate.checks.markup.XMLTagsCheck',
    'weblate.checks.source.OptionalPluralCheck',
    'weblate.checks.source.EllipsisCheck',
    'weblate.checks.source.MultipleFailingCheck',
)

Nota

Once you change this setting the existing checks will still be stored in the database, only newly changed translations will be affected by the change. To apply the change to the stored translations, you need to run updatechecks.

Ver también

Quality checks, Customizing behavior

COMMIT_PENDING_HOURS¶

Nuevo en la versión 2.10.

Default interval for committing pending changes using commit_pending.

Ver también

Running maintenance tasks, commit_pending

DATA_DIR¶

Directory where Weblate stores all data. This consists of VCS repositories, fulltext index and various configuration files for external tools.

The following subdirectories usually exist:

home: Home directory used for invoking scripts.
ssh: SSH keys and configuration.
static: Default location for Django static files, specified by STATIC_ROOT.
media: Default location for Django media files, specified by MEDIA_ROOT.
memory: Translation memory data using Whoosh engine (see Translation Memory).
vcs: Version control repositories.
whoosh: Fulltext search index using Whoosh engine.
backups: Dump of data in daily backups, see Dumped data for backups.

Nota

This directory has to be writable by Weblate. If you are running Weblate as uwsgi this means that it should be writable by the www-data user.

The easiest way to achieve is to make the user own the directory:

sudo chown www-data:www-data -R $DATA_DIR

Defaults to $BASE_DIR/data.

Ver también

BASE_DIR, Backing up and moving Weblate

DEFAULT_ACCESS_CONTROL¶

Nuevo en la versión 3.3.

Choose default access control when creating new project, possible values are currently:

0: Public
1: Protected
100: Private
200: Custom

Use Custom if you are going to manage ACL manually and do not want to rely on Weblate internal management.

Ver también

Per project access control, Access control

DEFAULT_COMMITER_EMAIL¶

Nuevo en la versión 2.4.

Default committer email when creating translation component (see Component configuration), defaults to noreply@weblate.org.

Ver también

DEFAULT_COMMITER_NAME, Component configuration

DEFAULT_COMMITER_NAME¶

Nuevo en la versión 2.4.

Default committer name when creating translation component (see Component configuration), defaults to Weblate.

Ver también

DEFAULT_COMMITER_EMAIL, Component configuration

DEFAULT_MERGE_STYLE¶

Nuevo en la versión 3.4.

Default merge style for new components (see Component configuration), choose one of:

rebase - default
merge

DEFAULT_TRANSLATION_PROPAGATION¶

Nuevo en la versión 2.5.

Default setting for translation propagation (see Component configuration), defaults to True.

Ver también

Component configuration

DEFAULT_PULL_MESSAGE¶

Default pull request title, defaults to 'Update from Weblate'.

ENABLE_AVATARS¶

Whether to enable Gravatar based avatars for users. By default this is enabled.

The avatars are fetched and cached on the server, so there is no risk in leaking private information or slowing down the user experiences with enabling this.

Ver también

Avatar caching, AVATAR_URL_PREFIX, Avatars

ENABLE_HOOKS¶

Whether to enable anonymous remote hooks.

Ver también

Notification hooks

ENABLE_HTTPS¶

Whether to send links to Weblate as https or http. This setting affects sent mails and generated absolute URLs.

Ver también

Pushing changes to GitHub as pull request, Setting up hub

GITHUB_USERNAME¶

GitHub username that will be used to send pull requests for translation updates.

Ver también

GOOGLE_ANALYTICS_ID¶

Google Analytics ID to enable monitoring of Weblate using Google Analytics.

HIDE_REPO_CREDENTIALS¶

Hide repository credentials in the web interface. In case you have repository URL with user and password, Weblate will hide it when showing it to the users.

For example instead of https://user:password@git.example.com/repo.git it will show just https://git.example.com/repo.git. It tries to cleanup VCS error messages as well in similar manner.

This is enabled by default.

IP_BEHIND_REVERSE_PROXY¶

Nuevo en la versión 2.14.

Indicates whether Weblate is running behind a reverse proxy.

If set to True, Weblate gets IP address from header defined by IP_BEHIND_REVERSE_PROXY. Ensure that you are actually using reverse proxy and that it sets this header, otherwise users will be able to fake the IP address.

Defaults to False.

Ver también

Rate limiting, IP address for rate limiting

IP_PROXY_HEADER¶

Nuevo en la versión 2.14.

Indicates from which header Weblate should obtain the IP address when IP_BEHIND_REVERSE_PROXY is enabled.

Defaults to HTTP_X_FORWARDED_FOR.

Ver también

Rate limiting, IP address for rate limiting

IP_PROXY_OFFSET¶

Nuevo en la versión 2.14.

Indicates which part of IP_BEHIND_REVERSE_PROXY is used as client IP address.

Depending on your setup, this header might consist of several IP addresses, (for example X-Forwarded-For: a, b, client-ip) and you can configure here which address from the header is client IP address.

Defaults to 0.

Ver también

Rate limiting, IP address for rate limiting

LOGIN_REQUIRED_URLS_EXCEPTIONS¶

List of exceptions for LOGIN_REQUIRED_URLS. If you don’t specify this list, the default value will be used, which allows users to access the login page.

Some of exceptions you might want to include:

LOGIN_REQUIRED_URLS_EXCEPTIONS = (
    r'/accounts/(.*)$', # Required for login
    r'/static/(.*)$',   # Required for development mode
    r'/widgets/(.*)$',  # Allowing public access to widgets
    r'/data/(.*)$',     # Allowing public access to data exports
    r'/hooks/(.*)$',    # Allowing public access to notification hooks
    r'/api/(.*)$',      # Allowing access to API
    r'/js/i18n/$',      # Javascript localization
)

MT_SERVICES¶

Distinto en la versión 3.0: The setting was renamed from MACHINE_TRANSLATION_SERVICES to MT_SERVICES to be consistent with other machine translation settings.

List of enabled machine translation services to use.

Nota

Many of services need additional configuration like API keys, please check their documentation for more details.

MT_SERVICES = (
    'weblate.machinery.apertium.ApertiumAPYTranslation',
    'weblate.machinery.deepl.DeepLTranslation',
    'weblate.machinery.glosbe.GlosbeTranslation',
    'weblate.machinery.google.GoogleTranslation',
    'weblate.machinery.microsoft.MicrosoftCognitiveTranslation',
    'weblate.machinery.microsoftterminology.MicrosoftTerminologyService',
    'weblate.machinery.mymemory.MyMemoryTranslation',
    'weblate.machinery.tmserver.AmagamaTranslation',
    'weblate.machinery.tmserver.TMServerTranslation',
    'weblate.machinery.yandex.YandexTranslation',
    'weblate.machinery.weblatetm.WeblateTranslation',
    'weblate.machinery.saptranslationhub.SAPTranslationHub',
    'weblate.memory.machine.WeblateMemory',
)

Ver también

Machine translation, Machine translation

MT_APERTIUM_APY¶

URL of the Apertium APy server, see http://wiki.apertium.org/wiki/Apertium-apy

Ver también

Apertium, Machine translation, Machine translation

MT_AWS_ACCESS_KEY_ID¶

Access key ID for Amazon Translate.

Ver también

AWS, Machine translation, Machine translation

MT_AWS_SECRET_ACCESS_KEY¶

API secret key for Amazon Translate.

Ver también

AWS, Machine translation, Machine translation

MT_AWS_REGION¶

Region name to use for Amazon Translate.

Ver también

AWS, Machine translation, Machine translation

MT_BAIDU_ID¶

Client ID for Baidu Zhiyun API, you can register at https://api.fanyi.baidu.com/api/trans/product/index

Ver también

Baidu API machine translation, Machine translation, Machine translation

MT_BAIDU_SECRET¶

Client secret for Baidu Zhiyun API, you can register at https://api.fanyi.baidu.com/api/trans/product/index

Ver también

Baidu API machine translation, Machine translation, Machine translation

MT_DEEPL_KEY¶

API key for DeepL API, you can register at https://www.deepl.com/pro.html.

Ver también

DeepL, Machine translation, Machine translation

MT_GOOGLE_KEY¶

API key for Google Translate API, you can register at https://cloud.google.com/translate/docs

Ver también

Google Translate, Machine translation, Machine translation

MT_MICROSOFT_COGNITIVE_KEY¶

Client key for Microsoft Cognitive Services Translator API.

Ver también

Microsoft Cognitive Services Translator, Machine translation, Machine translation, Cognitive Services - Text Translation API, Microsoft Azure Portal

MT_MYMEMORY_EMAIL¶

MyMemory identification email, you can get 1000 requests per day with this.

Ver también

MyMemory, Machine translation, Machine translation, MyMemory: API technical specifications

MT_MYMEMORY_KEY¶

MyMemory access key for private translation memory, use together with MT_MYMEMORY_USER.

Ver también

MyMemory, Machine translation, Machine translation, MyMemory: API key generator

MT_MYMEMORY_USER¶

MyMemory user id for private translation memory, use together with MT_MYMEMORY_KEY.

Ver también

MyMemory, Machine translation, Machine translation, MyMemory: API key generator

MT_NETEASE_KEY¶

App key for Netease Sight API, you can register at https://sight.netease.com/

Ver también

Netease Sight API machine translation, Machine translation, Machine translation

MT_NETEASE_SECRET¶

App secret for Netease Sight API, you can register at https://sight.netease.com/

Ver también

Netease Sight API machine translation, Machine translation, Machine translation

MT_TMSERVER¶

URL where tmserver is running.

Ver también

tmserver, Machine translation, Machine translation, tmserver

MT_YANDEX_KEY¶

API key for Yandex Translate API, you can register at https://tech.yandex.com/translate/

Ver también

Yandex Translate, Machine translation, Machine translation

MT_YOUDAO_ID¶

Client ID for Youdao Zhiyun API, you can register at https://ai.youdao.com/product-fanyi.s

Ver también

Youdao Zhiyun API machine translation, Machine translation, Machine translation

MT_YOUDAO_SECRET¶

Client secret for Youdao Zhiyun API, you can register at https://ai.youdao.com/product-fanyi.s

Ver también

Youdao Zhiyun API machine translation, Machine translation, Machine translation

MT_SAP_BASE_URL¶

API URL to the SAP Translation Hub service.

Ver también

SAP Translation Hub, Machine translation, Machine translation

MT_SAP_SANDBOX_APIKEY¶

API key for sandbox API usage

Ver también

SAP Translation Hub, Machine translation, Machine translation

MT_SAP_USERNAME¶

Your SAP username

Ver también

SAP Translation Hub, Machine translation, Machine translation

MT_SAP_PASSWORD¶

Your SAP password

Ver también

SAP Translation Hub, Machine translation, Machine translation

MT_SAP_USE_MT¶

Should the machine translation service also be used? (in addition to the term database). Possible values: True / False

Ver también

SAP Translation Hub, Machine translation, Machine translation

NEARBY_MESSAGES¶

How many messages around current one to show during translating.

PIWIK_SITE_ID¶

ID of a site in Matomo you want to track.

Ver también

PIWIK_URL

PIWIK_URL¶

URL of a Matomo installation you want to use to track Weblate users. For more information about Matomo see <https://matomo.org/>.

Ver también

PIWIK_SITE_ID

REGISTRATION_CAPTCHA¶

A boolean (either True or False) indicating whether registration of new accounts is protected by captcha. This setting is optional, and a default of True will be assumed if it is not supplied.

If enabled the captcha is added to all pages where users enter email address:

New account registration.
Password recovery.
Adding email to an account.
Contact form for users who are not logged in.

REGISTRATION_EMAIL_MATCH¶

Nuevo en la versión 2.17.

Allows you to filter email addresses which can register.

Defaults to .* which allows any address to register.

You can use it to restrict registration to a single email domain:

REGISTRATION_EMAIL_MATCH = r'^.*@weblate\.org$'

REGISTRATION_OPEN¶

A boolean (either True or False) indicating whether registration of new accounts is currently permitted. This setting is optional, and a default of True will be assumed if it is not supplied.

SIMPLIFY_LANGUAGES¶

Use simple language codes for default language/country combinations. For example fr_FR translation will use fr language code. This is usually desired behavior as it simplifies listing of the languages for these default combinations.

Disable this if you are having different translations for both variants.

SITE_TITLE¶

Site title to be used in website and emails as well.

SPECIAL_CHARS¶

Additional chars to show in the visual keyboard, see Visual keyboard.

The default value is:

SPECIAL_CHARS = ('\t', '\n', '…')

STATUS_URL¶

URL where your Weblate instance reports it’s status.

SUGGESTION_CLEANUP_DAYS¶

Nuevo en la versión 3.2.1.

Automatically delete suggestions after given number of days. Defaults to None what means no deletion at all.

TTF_PATH¶

Path to Droid fonts used for widgets and charts.

Defaults to $BASE_DIR/weblate/ttf.

Ver también

BASE_DIR

URL_PREFIX¶

This settings allows you to run Weblate under some path (otherwise it relies on being executed from webserver root). To use this setting, you also need to configure your server to strip this prefix. For example with WSGI, this can be achieved by setting WSGIScriptAlias.

Nota

This setting does not work with Django’s builtin server, you would have to adjust urls.py to contain this prefix.

WEBLATE_ADDONS¶

List of addons available for use. To use them, they have to be enabled for given translation component. By default this includes all built in addons, when extending the list you will probably want to keep existing ones enabled, for example:

WEBLATE_ADDONS = (
    # Built in addons
    'weblate.addons.gettext.GenerateMoAddon',
    'weblate.addons.gettext.UpdateLinguasAddon',
    'weblate.addons.gettext.UpdateConfigureAddon',
    'weblate.addons.gettext.MsgmergeAddon',
    'weblate.addons.gettext.GettextCustomizeAddon',
    'weblate.addons.gettext.GettextAuthorComments',
    'weblate.addons.cleanup.CleanupAddon',
    'weblate.addons.consistency.LangaugeConsistencyAddon',
    'weblate.addons.discovery.DiscoveryAddon',
    'weblate.addons.flags.SourceEditAddon',
    'weblate.addons.flags.TargetEditAddon',
    'weblate.addons.flags.SameEditAddon',
    'weblate.addons.generate.GenerateFileAddon',
    'weblate.addons.json.JSONCustomizeAddon',
    'weblate.addons.properties.PropertiesSortAddon',

    # Addon you want to include
    'weblate.addons.example.ExampleAddon',
)

Ver también

Addons

WEBLATE_FORMATS¶

Nuevo en la versión 3.0.

List of file formats available for use, you can usually keep this on default value.

Ver también

Supported formats

WEBLATE_GPG_IDENTITY¶

Nuevo en la versión 3.1.

Identity which should be used by Weblate to sign Git commits, for example:

WEBLATE_GPG_IDENTITY = 'Weblate <weblate@example.com>'

Advertencia

If you are going to change value of setting, it is advisable to clean the cache as the key information is cached for seven days. This is not necessary for initial setup as nothing is cached if this feature is not configured.

Ver también

Signing Git commits by GnuPG

Sample configuration¶

The following example is shipped as weblate/settings_example.py with Weblate:

# -*- coding: utf-8 -*-
#
# Copyright © 2012 - 2019 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#

from __future__ import unicode_literals
import platform
import os
from logging.handlers import SysLogHandler

#
# Django settings for Weblate project.
#

DEBUG = True

ADMINS = (
    # ('Your Name', 'your_email@example.com'),
)

MANAGERS = ADMINS

DATABASES = {
    'default': {
        # Use 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'ENGINE': 'django.db.backends.sqlite3',
        # Database name or path to database file if using sqlite3.
        'NAME': 'weblate.db',
        # Database user, not used with sqlite3.
        'USER': 'weblate',
        # Database password, not used with sqlite3.
        'PASSWORD': 'weblate',
        # Set to empty string for localhost. Not used with sqlite3.
        'HOST': '127.0.0.1',
        # Set to empty string for default. Not used with sqlite3.
        'PORT': '',
        # Customizations for databases
        'OPTIONS': {
            # In case of using an older MySQL server, which has MyISAM as a default storage
            # 'init_command': 'SET storage_engine=INNODB',
            # Uncomment for MySQL older than 5.7:
            # 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
            # Set emoji capable charset for MySQL:
            # 'charset': 'utf8mb4',
        },
    }
}

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

# Data directory
DATA_DIR = os.path.join(BASE_DIR, 'data')

# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# In a Windows environment this must be set to your system time zone.
TIME_ZONE = 'UTC'

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'

LANGUAGES = (
    ('ar', 'العربية'),
    ('az', 'Azərbaycan'),
    ('be', 'Беларуская'),
    ('be@latin', 'Biełaruskaja'),
    ('bg', 'Български'),
    ('br', 'Brezhoneg'),
    ('ca', 'Català'),
    ('cs', 'Čeština'),
    ('da', 'Dansk'),
    ('de', 'Deutsch'),
    ('en', 'English'),
    ('en-gb', 'English (United Kingdom)'),
    ('el', 'Ελληνικά'),
    ('es', 'Español'),
    ('fi', 'Suomi'),
    ('fr', 'Français'),
    ('fy', 'Frysk'),
    ('gl', 'Galego'),
    ('he', 'עברית'),
    ('hu', 'Magyar'),
    ('id', 'Indonesia'),
    ('it', 'Italiano'),
    ('ja', '日本語'),
    ('ko', '한국어'),
    ('ksh', 'Kölsch'),
    ('nb', 'Norsk bokmål'),
    ('nl', 'Nederlands'),
    ('pl', 'Polski'),
    ('pt', 'Português'),
    ('pt-br', 'Português brasileiro'),
    ('ru', 'Русский'),
    ('sk', 'Slovenčina'),
    ('sl', 'Slovenščina'),
    ('sr', 'Српски'),
    ('sv', 'Svenska'),
    ('tr', 'Türkçe'),
    ('uk', 'Українська'),
    ('zh-hans', '简体字'),
    ('zh-hant', '正體字'),
)

SITE_ID = 1

# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = True

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale.
USE_L10N = True

# If you set this to False, Django will not use timezone-aware datetimes.
USE_TZ = True

# URL prefix to use, please see documentation for more details
URL_PREFIX = ''

# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = os.path.join(DATA_DIR, 'media')

# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash.
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = '{0}/media/'.format(URL_PREFIX)

# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/"
STATIC_ROOT = os.path.join(DATA_DIR, 'static')

# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '{0}/static/'.format(URL_PREFIX)

# Additional locations of static files
STATICFILES_DIRS = (
    # Put strings here, like "/home/html/static" or "C:/www/django/static".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
)

# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
    'compressor.finders.CompressorFinder',
)

# Make this unique, and don't share it with anybody.
# You can generate it using examples/generate-secret-key
SECRET_KEY = 'jm8fqjlg+5!#xu%e-oh#7!$aa7!6avf7ud*_v=chdrb9qdco6('  # noqa

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            os.path.join(BASE_DIR, 'weblate', 'templates'),
        ],
        'OPTIONS': {
            'context_processors': [
                'django.contrib.auth.context_processors.auth',
                'django.template.context_processors.debug',
                'django.template.context_processors.i18n',
                'django.template.context_processors.request',
                'django.template.context_processors.csrf',
                'django.contrib.messages.context_processors.messages',
                'weblate.trans.context_processors.weblate_context',
            ],
            'loaders': [
                ('django.template.loaders.cached.Loader', [
                    'django.template.loaders.filesystem.Loader',
                    'django.template.loaders.app_directories.Loader',
                ]),
            ],
        },
    },
]


# GitHub username for sending pull requests.
# Please see the documentation for more details.
GITHUB_USERNAME = None

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    'social_core.backends.email.EmailAuth',
    # 'social_core.backends.google.GoogleOAuth2',
    # 'social_core.backends.github.GithubOAuth2',
    # 'social_core.backends.bitbucket.BitbucketOAuth',
    # 'social_core.backends.suse.OpenSUSEOpenId',
    # 'social_core.backends.ubuntu.UbuntuOpenId',
    # 'social_core.backends.fedora.FedoraOpenId',
    # 'social_core.backends.facebook.FacebookOAuth2',
    'weblate.accounts.auth.WeblateUserBackend',
)

# Custom user model
AUTH_USER_MODEL = 'weblate_auth.User'

# Social auth backends setup
SOCIAL_AUTH_GITHUB_KEY = ''
SOCIAL_AUTH_GITHUB_SECRET = ''
SOCIAL_AUTH_GITHUB_SCOPE = ['user:email']

SOCIAL_AUTH_BITBUCKET_KEY = ''
SOCIAL_AUTH_BITBUCKET_SECRET = ''
SOCIAL_AUTH_BITBUCKET_VERIFIED_EMAILS_ONLY = True

SOCIAL_AUTH_FACEBOOK_KEY = ''
SOCIAL_AUTH_FACEBOOK_SECRET = ''
SOCIAL_AUTH_FACEBOOK_SCOPE = ['email', 'public_profile']
SOCIAL_AUTH_FACEBOOK_PROFILE_EXTRA_PARAMS = {'fields': 'id,name,email'}
SOCIAL_AUTH_FACEBOOK_API_VERSION = '3.1'

SOCIAL_AUTH_GOOGLE_OAUTH2_KEY = ''
SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET = ''

# Social auth settings
SOCIAL_AUTH_PIPELINE = (
    'social_core.pipeline.social_auth.social_details',
    'social_core.pipeline.social_auth.social_uid',
    'social_core.pipeline.social_auth.auth_allowed',
    'social_core.pipeline.social_auth.social_user',
    'weblate.accounts.pipeline.store_params',
    'weblate.accounts.pipeline.verify_open',
    'social_core.pipeline.user.get_username',
    'weblate.accounts.pipeline.require_email',
    'social_core.pipeline.mail.mail_validation',
    'weblate.accounts.pipeline.revoke_mail_code',
    'weblate.accounts.pipeline.ensure_valid',
    'weblate.accounts.pipeline.remove_account',
    'social_core.pipeline.social_auth.associate_by_email',
    'weblate.accounts.pipeline.reauthenticate',
    'weblate.accounts.pipeline.verify_username',
    'social_core.pipeline.user.create_user',
    'social_core.pipeline.social_auth.associate_user',
    'social_core.pipeline.social_auth.load_extra_data',
    'weblate.accounts.pipeline.cleanup_next',
    'weblate.accounts.pipeline.user_full_name',
    'weblate.accounts.pipeline.store_email',
    'weblate.accounts.pipeline.notify_connect',
    'weblate.accounts.pipeline.password_reset',
)
SOCIAL_AUTH_DISCONNECT_PIPELINE = (
    'social_core.pipeline.disconnect.allowed_to_disconnect',
    'social_core.pipeline.disconnect.get_entries',
    'social_core.pipeline.disconnect.revoke_tokens',
    'weblate.accounts.pipeline.cycle_session',
    'weblate.accounts.pipeline.adjust_primary_mail',
    'weblate.accounts.pipeline.notify_disconnect',
    'social_core.pipeline.disconnect.disconnect',
    'weblate.accounts.pipeline.cleanup_next',
)

# Custom authentication strategy
SOCIAL_AUTH_STRATEGY = 'weblate.accounts.strategy.WeblateStrategy'

# Raise exceptions so that we can handle them later
SOCIAL_AUTH_RAISE_EXCEPTIONS = True

SOCIAL_AUTH_EMAIL_VALIDATION_FUNCTION = \
    'weblate.accounts.pipeline.send_validation'
SOCIAL_AUTH_EMAIL_VALIDATION_URL = \
    '{0}/accounts/email-sent/'.format(URL_PREFIX)
SOCIAL_AUTH_LOGIN_ERROR_URL = \
    '{0}/accounts/login/'.format(URL_PREFIX)
SOCIAL_AUTH_EMAIL_FORM_URL = \
    '{0}/accounts/email/'.format(URL_PREFIX)
SOCIAL_AUTH_NEW_ASSOCIATION_REDIRECT_URL = \
    '{0}/accounts/profile/#auth'.format(URL_PREFIX)
SOCIAL_AUTH_PROTECTED_USER_FIELDS = ('email',)
SOCIAL_AUTH_SLUGIFY_USERNAMES = True
SOCIAL_AUTH_SLUGIFY_FUNCTION = 'weblate.accounts.pipeline.slugify_username'

# Password validation configuration
AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 6,
        }
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
    {
        'NAME': 'weblate.accounts.password_validation.CharsPasswordValidator',
    },
    {
        'NAME': 'weblate.accounts.password_validation.PastPasswordsValidator',
    },
    # Optional password strength validation by django-zxcvbn-password
    # {
    #     'NAME': 'zxcvbn_password.ZXCVBNValidator',
    #     'OPTIONS': {
    #         'min_score': 3,
    #         'user_attributes': ('username', 'email', 'full_name')
    #     }
    # },
]

# Allow new user registrations
REGISTRATION_OPEN = True

# Middleware
MIDDLEWARE = [
    'weblate.middleware.ProxyMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'weblate.accounts.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'social_django.middleware.SocialAuthExceptionMiddleware',
    'weblate.accounts.middleware.RequireLoginMiddleware',
    'weblate.middleware.SecurityMiddleware',
]

ROOT_URLCONF = 'weblate.urls'

# Django and Weblate apps
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.admin.apps.SimpleAdminConfig',
    'django.contrib.admindocs',
    'django.contrib.sitemaps',
    'social_django',
    'crispy_forms',
    'compressor',
    'rest_framework',
    'rest_framework.authtoken',
    'weblate.addons',
    'weblate.auth',
    'weblate.checks',
    'weblate.formats',
    'weblate.machinery',
    'weblate.trans',
    'weblate.lang',
    'weblate.langdata',
    'weblate.memory',
    'weblate.screenshots',
    'weblate.accounts',
    'weblate.utils',
    'weblate.vcs',
    'weblate.wladmin',
    'weblate',

    # Optional: Git exporter
    # 'weblate.gitexport',
)

# Path to locales
LOCALE_PATHS = (os.path.join(BASE_DIR, 'weblate', 'locale'), )

# Custom exception reporter to include some details
DEFAULT_EXCEPTION_REPORTER_FILTER = \
    'weblate.trans.debug.WeblateExceptionReporterFilter'

# Default logging of Weblate messages
# - to syslog in production (if available)
# - otherwise to console
# - you can also choose 'logfile' to log into separate file
#   after configuring it below

# Detect if we can connect to syslog
HAVE_SYSLOG = False
if platform.system() != 'Windows':
    try:
        handler = SysLogHandler(
            address='/dev/log', facility=SysLogHandler.LOG_LOCAL2
        )
        handler.close()
        HAVE_SYSLOG = True
    except IOError:
        HAVE_SYSLOG = False

if DEBUG or not HAVE_SYSLOG:
    DEFAULT_LOG = 'console'
else:
    DEFAULT_LOG = 'syslog'

# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See http://docs.djangoproject.com/en/stable/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'formatters': {
        'syslog': {
            'format': 'weblate[%(process)d]: %(levelname)s %(message)s'
        },
        'simple': {
            'format': '%(levelname)s %(message)s'
        },
        'logfile': {
            'format': '%(asctime)s %(levelname)s %(message)s'
        },
        'django.server': {
            '()': 'django.utils.log.ServerFormatter',
            'format': '[%(server_time)s] %(message)s',
        }
    },
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler',
            'include_html': True,
        },
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'simple'
        },
        'django.server': {
            'level': 'INFO',
            'class': 'logging.StreamHandler',
            'formatter': 'django.server',
        },
        'syslog': {
            'level': 'DEBUG',
            'class': 'logging.handlers.SysLogHandler',
            'formatter': 'syslog',
            'address': '/dev/log',
            'facility': SysLogHandler.LOG_LOCAL2,
        },
        # Logging to a file
        # 'logfile': {
        #     'level':'DEBUG',
        #     'class':'logging.handlers.RotatingFileHandler',
        #     'filename': "/var/log/weblate/weblate.log",
        #     'maxBytes': 100000,
        #     'backupCount': 3,
        #     'formatter': 'logfile',
        # },
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins', DEFAULT_LOG],
            'level': 'ERROR',
            'propagate': True,
        },
        'django.server': {
            'handlers': ['django.server'],
            'level': 'INFO',
            'propagate': False,
        },
        # Logging database queries
        # 'django.db.backends': {
        #     'handlers': [DEFAULT_LOG],
        #     'level': 'DEBUG',
        # },
        'weblate': {
            'handlers': [DEFAULT_LOG],
            'level': 'DEBUG',
        },
        # Logging search operations
        'weblate.search': {
            'handlers': [DEFAULT_LOG],
            'level': 'INFO',
        },
        # Logging VCS operations
        'weblate.vcs': {
            'handlers': [DEFAULT_LOG],
            'level': 'WARNING',
        },
        # Python Social Auth logging
        # 'social': {
        #     'handlers': [DEFAULT_LOG],
        #     'level': 'DEBUG',
        # },
    }
}

# Logging of management commands to console
if (os.environ.get('DJANGO_IS_MANAGEMENT_COMMAND', False) and
        'console' not in LOGGING['loggers']['weblate']['handlers']):
    LOGGING['loggers']['weblate']['handlers'].append('console')

# Remove syslog setup if it's not present
if not HAVE_SYSLOG:
    del LOGGING['handlers']['syslog']

# List of machine translations
# MT_SERVICES = (
#     'weblate.machinery.apertium.ApertiumAPYTranslation',
#     'weblate.machinery.baidu.BaiduTranslation',
#     'weblate.machinery.deepl.DeepLTranslation',
#     'weblate.machinery.glosbe.GlosbeTranslation',
#     'weblate.machinery.google.GoogleTranslation',
#     'weblate.machinery.microsoft.MicrosoftCognitiveTranslation',
#     'weblate.machinery.microsoftterminology.MicrosoftTerminologyService',
#     'weblate.machinery.mymemory.MyMemoryTranslation',
#     'weblate.machinery.netease.NeteaseSightTranslation',
#     'weblate.machinery.tmserver.AmagamaTranslation',
#     'weblate.machinery.tmserver.TMServerTranslation',
#     'weblate.machinery.yandex.YandexTranslation',
#     'weblate.machinery.weblatetm.WeblateTranslation',
#     'weblate.machinery.saptranslationhub.SAPTranslationHub',
#     'weblate.machinery.youdao.YoudaoTranslation',
#     'weblate.memory.machine.WeblateMemory',
# )

# Machine translation API keys

# URL of the Apertium APy server
MT_APERTIUM_APY = None

# DeepL API key
MT_DEEPL_KEY = None

# Microsoft Cognitive Services Translator API, register at
# https://portal.azure.com/
MT_MICROSOFT_COGNITIVE_KEY = None

# MyMemory identification email, see
# https://mymemory.translated.net/doc/spec.php
MT_MYMEMORY_EMAIL = None

# Optional MyMemory credentials to access private translation memory
MT_MYMEMORY_USER = None
MT_MYMEMORY_KEY = None

# Google API key for Google Translate API
MT_GOOGLE_KEY = None

# Baidu app key and secret
MT_BAIDU_ID = None
MT_BAIDU_SECRET = None

# Youdao Zhiyun app key and secret
MT_YOUDAO_ID = None
MT_YOUDAO_SECRET = None

# Netease Sight (Jianwai) app key and secret
MT_NETEASE_KEY = None
MT_NETEASE_SECRET = None

# API key for Yandex Translate API
MT_YANDEX_KEY = None

# tmserver URL
MT_TMSERVER = None

# SAP Translation Hub
MT_SAP_BASE_URL = None
MT_SAP_SANDBOX_APIKEY = None
MT_SAP_USERNAME = None
MT_SAP_PASSWORD = None
MT_SAP_USE_MT = True

# Title of site to use
SITE_TITLE = 'Weblate'

# Whether site uses https
ENABLE_HTTPS = False

# Use HTTPS when creating redirect URLs for social authentication, see
# documentation for more details:
# https://python-social-auth-docs.readthedocs.io/en/latest/configuration/settings.html#processing-redirects-and-urlopen
SOCIAL_AUTH_REDIRECT_IS_HTTPS = ENABLE_HTTPS

# Make CSRF cookie HttpOnly, see documentation for more details:
# https://docs.djangoproject.com/en/1.11/ref/settings/#csrf-cookie-httponly
CSRF_COOKIE_HTTPONLY = True
CSRF_COOKIE_SECURE = ENABLE_HTTPS
# Store CSRF token in session (since Django 1.11)
CSRF_USE_SESSIONS = True
SESSION_COOKIE_SECURE = ENABLE_HTTPS
# SSL redirect
SECURE_SSL_REDIRECT = ENABLE_HTTPS
# Session cookie age (in seconds)
SESSION_COOKIE_AGE = 1209600

# Some security headers
SECURE_BROWSER_XSS_FILTER = True
X_FRAME_OPTIONS = 'DENY'
SECURE_CONTENT_TYPE_NOSNIFF = True

# Optionally enable HSTS
SECURE_HSTS_SECONDS = 0
SECURE_HSTS_PRELOAD = False
SECURE_HSTS_INCLUDE_SUBDOMAINS = False

# URL of login
LOGIN_URL = '{0}/accounts/login/'.format(URL_PREFIX)

# URL of logout
LOGOUT_URL = '{0}/accounts/logout/'.format(URL_PREFIX)

# Default location for login
LOGIN_REDIRECT_URL = '{0}/'.format(URL_PREFIX)

# Anonymous user name
ANONYMOUS_USER_NAME = 'anonymous'

# Reverse proxy settings
IP_PROXY_HEADER = 'HTTP_X_FORWARDED_FOR'
IP_BEHIND_REVERSE_PROXY = False
IP_PROXY_OFFSET = 0

# Sending HTML in mails
EMAIL_SEND_HTML = True

# Subject of emails includes site title
EMAIL_SUBJECT_PREFIX = '[{0}] '.format(SITE_TITLE)

# Enable remote hooks
ENABLE_HOOKS = True

# Number of nearby messages to show in each direction
NEARBY_MESSAGES = 5

# Use simple language codes for default language/country combinations
SIMPLIFY_LANGUAGES = True

# Render forms using bootstrap
CRISPY_TEMPLATE_PACK = 'bootstrap3'

# List of quality checks
# CHECK_LIST = (
#     'weblate.checks.same.SameCheck',
#     'weblate.checks.chars.BeginNewlineCheck',
#     'weblate.checks.chars.EndNewlineCheck',
#     'weblate.checks.chars.BeginSpaceCheck',
#     'weblate.checks.chars.EndSpaceCheck',
#     'weblate.checks.chars.EndStopCheck',
#     'weblate.checks.chars.EndColonCheck',
#     'weblate.checks.chars.EndQuestionCheck',
#     'weblate.checks.chars.EndExclamationCheck',
#     'weblate.checks.chars.EndEllipsisCheck',
#     'weblate.checks.chars.EndSemicolonCheck',
#     'weblate.checks.chars.MaxLengthCheck',
#     'weblate.checks.format.PythonFormatCheck',
#     'weblate.checks.format.PythonBraceFormatCheck',
#     'weblate.checks.format.PHPFormatCheck',
#     'weblate.checks.format.CFormatCheck',
#     'weblate.checks.format.PerlFormatCheck',
#     'weblate.checks.format.JavascriptFormatCheck',
#     'weblate.checks.format.CSharpFormatCheck',
#     'weblate.checks.format.JavaFormatCheck',
#     'weblate.checks.format.JavaMessageFormatCheck',
#     'weblate.checks.angularjs.AngularJSInterpolationCheck',
#     'weblate.checks.consistency.PluralsCheck',
#     'weblate.checks.consistency.SamePluralsCheck',
#     'weblate.checks.consistency.ConsistencyCheck',
#     'weblate.checks.consistency.TranslatedCheck',
#     'weblate.checks.chars.NewlineCountingCheck',
#     'weblate.checks.markup.BBCodeCheck',
#     'weblate.checks.chars.ZeroWidthSpaceCheck',
#     'weblate.checks.markup.XMLValidityCheck',
#     'weblate.checks.markup.XMLTagsCheck',
#     'weblate.checks.source.OptionalPluralCheck',
#     'weblate.checks.source.EllipsisCheck',
#     'weblate.checks.source.MultipleFailingCheck',
# )

# List of automatic fixups
# AUTOFIX_LIST = (
#     'weblate.trans.autofixes.whitespace.SameBookendingWhitespace',
#     'weblate.trans.autofixes.chars.ReplaceTrailingDotsWithEllipsis',
#     'weblate.trans.autofixes.chars.RemoveZeroSpace',
#     'weblate.trans.autofixes.chars.RemoveControlChars',
# )

# List of enabled addons
# WEBLATE_ADDONS = (
#     'weblate.addons.gettext.GenerateMoAddon',
#     'weblate.addons.gettext.UpdateLinguasAddon',
#     'weblate.addons.gettext.UpdateConfigureAddon',
#     'weblate.addons.gettext.MsgmergeAddon',
#     'weblate.addons.gettext.GettextCustomizeAddon',
#     'weblate.addons.gettext.GettextAuthorComments',
#     'weblate.addons.cleanup.CleanupAddon',
#     'weblate.addons.consistency.LangaugeConsistencyAddon',
#     'weblate.addons.discovery.DiscoveryAddon',
#     'weblate.addons.flags.SourceEditAddon',
#     'weblate.addons.flags.TargetEditAddon',
#     'weblate.addons.generate.GenerateFileAddon',
#     'weblate.addons.json.JSONCustomizeAddon',
#     'weblate.addons.properties.PropertiesSortAddon',
#     'weblate.addons.git.GitSquashAddon',
# )

# E-mail address that error messages come from.
SERVER_EMAIL = 'noreply@example.com'

# Default email address to use for various automated correspondence from
# the site managers. Used for registration emails.
DEFAULT_FROM_EMAIL = 'noreply@example.com'

# List of URLs your site is supposed to serve
ALLOWED_HOSTS = []

# Example configuration for caching
# CACHES = {
# Recommended redis + hiredis:
#     'default': {
#         'BACKEND': 'django_redis.cache.RedisCache',
#         'LOCATION': 'redis://127.0.0.1:6379/0',
#         # If redis is running on same host as Weblate, you might
#         # want to use unix sockets instead:
#         # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
#         'OPTIONS': {
#             'CLIENT_CLASS': 'django_redis.client.DefaultClient',
#             'PARSER_CLASS': 'redis.connection.HiredisParser',
#         }
#     },
# Memcached alternative:
#     'default': {
#         'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
#         'LOCATION': '127.0.0.1:11211',
#     },
#     'avatar': {
#         'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
#         'LOCATION': os.path.join(DATA_DIR, 'avatar-cache'),
#         'TIMEOUT': 3600,
#         'OPTIONS': {
#             'MAX_ENTRIES': 1000,
#         },
#     }
# }

# REST framework settings for API
REST_FRAMEWORK = {
    # Use Django's standard `django.contrib.auth` permissions,
    # or allow read-only access for unauthenticated users.
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticatedOrReadOnly'
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.TokenAuthentication',
        'weblate.api.authentication.BearerAuthentication',
        'rest_framework.authentication.SessionAuthentication',
    ),
    'DEFAULT_THROTTLE_CLASSES': (
        'rest_framework.throttling.AnonRateThrottle',
        'rest_framework.throttling.UserRateThrottle'
    ),
    'DEFAULT_THROTTLE_RATES': {
        'anon': '100/day',
        'user': '1000/day'
    },
    'DEFAULT_PAGINATION_CLASS': (
        'rest_framework.pagination.PageNumberPagination'
    ),
    'PAGE_SIZE': 20,
    'VIEW_DESCRIPTION_FUNCTION': 'weblate.api.views.get_view_description',
    'UNAUTHENTICATED_USER': 'weblate.auth.models.get_anonymous',
}

# Example for restricting access to logged in users
# LOGIN_REQUIRED_URLS = (
#     r'/(.*)$',
# )

# In such case you will want to include some of the exceptions
# LOGIN_REQUIRED_URLS_EXCEPTIONS = (
#    r'/accounts/(.*)$',        # Required for login
#    r'/admin/login/(.*)$',     # Required for admin login
#    r'/static/(.*)$',          # Required for development mode
#    r'/widgets/(.*)$',         # Allowing public access to widgets
#    r'/data/(.*)$',            # Allowing public access to data exports
#    r'/hooks/(.*)$',           # Allowing public access to notification hooks
#    r'/healthz/$',             # Allowing public access to health check
#    r'/api/(.*)$',             # Allowing access to API
#    r'/js/i18n/$',             # Javascript localization
#    r'/contact/$',             # Optional for contact form
#    r'/legal/(.*)$',           # Optional for legal app
# )

# Silence some of the Django system checks
SILENCED_SYSTEM_CHECKS = [
    # We have modified django.contrib.auth.middleware.AuthenticationMiddleware
    # as weblate.accounts.middleware.AuthenticationMiddleware
    'admin.E408',
]

# Celery worker configuration for testing
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = 'memory://'
CELERY_EAGER_PROPAGATES_EXCEPTIONS = True
# Celery worker configuration for production
# CELERY_TASK_ALWAYS_EAGER = False
# CELERY_BROKER_URL = 'redis://localhost:6379'
# CELERY_RESULT_BACKEND = CELERY_BROKER_URL

# Celery settings, it is not recommended to change these
CELERY_WORKER_PREFETCH_MULTIPLIER = 0
CELERY_BEAT_SCHEDULE_FILENAME = os.path.join(
    DATA_DIR, 'celery', 'beat-schedule'
)
CELERY_TASK_ROUTES = {
    'weblate.trans.search.*': {'queue': 'search'},
    'weblate.trans.tasks.optimize_fulltext': {'queue': 'search'},
    'weblate.trans.tasks.cleanup_fulltext': {'queue': 'search'},
    'weblate.memory.tasks.*': {'queue': 'memory'},
}

Management commands¶

Nota

Running management commands under a different user than is running your webserver can cause wrong permissions on some files, please check Filesystem permissions for more details.

Django comes with a management script (available as ./manage.py in sources or installed as weblate when Weblate is installed). It provides various management commands and Weblate extends it with several additional commands.

Invoking management commands¶

As mentioned before, invocation depends on how you have installed Weblate.

If you are using source code directly (either tarball or Git checkout), the management script is ./manage.py in Weblate sources. Execution can be done as:

python ./manage.py list_versions

If you’ve installed Weblate using PIP installer or by ./setup.py script, the weblate is installed to your path and you can use it to control Weblate:

weblate list_versions

For Docker image, the script is installed same as above, you can execute it using docker exec:

docker exec <container> weblate list_versions

With docker-compose this is quite similar, you just have to use docker-compose exec:

docker-compose exec weblate weblate list_versions

In case you need to pass some file, you can temporary add a volume:

docker-compose exec /tmp:/tmp weblate weblate importusers /tmp/users.json

Ver también

Running Weblate with Docker, Installing Weblate with pip

add_suggestions¶

manage.py add_suggestions <project> <component> <language> <file>¶

Nuevo en la versión 2.5.

Imports translation from the file as a suggestion to given translation. It skips translations which are the same as existing ones, only different ones are added.

--author USER@EXAMPLE.COM¶: Email of author for the suggestions. This user has to exist prior importing (you can create one in the admin interface if needed).

Example:

./manage.py --author michal@cihar.com add_suggestions weblate master cs /tmp/suggestions-cs.po

auto_translate¶

manage.py auto_translate <project> <component> <language>¶

Nuevo en la versión 2.5.

Performs automatic translation based on other component translations.

--source PROJECT/COMPONENT¶: Specifies component to use as source for translation. If not specified all components in the project are used.

--user USERNAME¶: Specify username who will be author of the translations. Anonymous user is used if not specified.

--overwrite¶: Whether to overwrite existing translations.

--inconsistent¶: Whether to overwrite existing translations which are inconsistent (see Inconsistent).

--add¶: Automatically add language if given translation does not exist.

--mt MT¶: Use machine translation instead of other components.

--threshold THRESHOLD¶: Similarity threshold for machine translation, defaults to 80.

Example:

./manage.py --user nijel --inconsistent --source phpmyadmin/master phpmyadmin 4-5 cs

Ver también

Automatic translation

changesite¶

manage.py changesite¶

Nuevo en la versión 2.4.

You can use this to change or display site name from command line without using admin interface.

--set-name NAME¶: Sets name for the site.

--get-name¶: Prints currently configured site name.

Ver también

Running maintenance tasks, COMMIT_PENDING_HOURS

checkgit¶

manage.py checkgit <project|project/component>¶

Prints current state of the backend git repository.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

commitgit¶

manage.py commitgit <project|project/component>¶

Commits any possible pending changes to backend git repository.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

commit_pending¶

manage.py commit_pending <project|project/component>¶

Commits pending changes older than given age.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

--age HOURS¶: Age in hours for committing. If not specified value configured in Component configuration is used.

Nota

This is automatically perfomed in the background by Weblate, so there is not much reason to invoke this manually besides forcing earlier commit than specified by Component configuration.

Ver también

cleanup_avatar_cache¶

Nuevo en la versión 3.1.

manage.py cleanup_avatar_cache¶

Removes invalid items in avatar cache. This can be useful when switching between Python 2 and 3 as the cache files might be not compatible.

cleanuptrans¶

manage.py cleanuptrans¶

Cleanups orphaned checks and translation suggestions. This is normally not needed to execute manually, the cleanups happen automatically in the background.

Ver también

Running maintenance tasks

createadmin¶

manage.py createadmin¶

Creates admin account with random password unless it is specified.

--password PASSWORD¶: Provide password on the command line and skip generating random one.

--no-password¶: Do not set password, this can be useful with –update.

--username USERNAME¶: Use given name instead of admin.

--email USER@EXAMPLE.COM¶: Specify admin email.

--name¶: Specify admin name (visible).

--update¶: Update existing user (you can use this to change password).

Distinto en la versión 2.9: Added parameters --username, --email, --name and --update.

delete_memory¶

manage.py delete_memory¶

Nuevo en la versión 2.20.

Deletes entries in the Weblate Translation Memory.

--origin ORIGIN¶: Origin to delete, for imported files the origin is filename without path.

--all¶: Delete complete memory content and recreate the database.

Ver también

dump_memory¶

manage.py dump_memory¶

Nuevo en la versión 2.20.

Export a JSON file with the Weblate Translation Memory content.

Ver también

dumpuserdata¶

manage.py dumpuserdata <file.json>¶

Dumps userdata to file for later use by importuserdata

This is useful when migrating or merging Weblate instances.

import_json¶

manage.py import_json <json-file>¶

Nuevo en la versión 2.7.

Batch import of components based on JSON data.

The imported JSON file structure pretty much corresponds to the component object (see GET /api/components/(string:project)/(string:component)/). You always have to include fields name and filemask.

--project PROJECT¶: Specifies where the components will be imported.

--main-component COMPONENT¶: Use VCS repository from this component for all.

--ignore¶: Skip already imported components.

--update¶: Update already imported components.

Distinto en la versión 2.9: Added parameters --ignore and --update to deal with already imported components.

Example of JSON file:

[
    {
        "slug": "po",
        "name": "Gettext PO",
        "file_format": "po",
        "filemask": "po/*.po",
        "new_lang": "none"
    },
    {
        "name": "Android",
        "filemask": "android/values-*/strings.xml",
        "template": "android/values/strings.xml",
        "repo": "weblate://test/test",
        "file_format": "aresource"
    }
]

Ver también

import_memory

import_memory¶

manage.py import_memory <file>¶

Nuevo en la versión 2.20.

Imports a TMX or JSON file into the Weblate Translation Memory.

--language-map LANGMAP¶

Allows to map languages in the TMX to Weblate one. The language codes are mapped after normalization usually done by Weblate.

For example --language-map en_US:en will import all en_US strings as en ones.

This can be useful in case your TMX file locales does not match what you use in Weblate.

Ver también

import_project¶

manage.py import_project <project> <gitrepo> <branch> <filemask>¶

Distinto en la versión 3.0: The import_project command is now based on the Component discovery addon and that has lead to some changes in behavior and accepted parameters.

Batch imports components into project based on file mask.

<project> names an existing project, into which the components should be imported.

The <gitrepo> defines URL of Git repository to use, and <branch> the git branch. To import additional translation components, from an existing Weblate component, use a weblate://<project>/<component> URL for the <gitrepo>.

The <filemask> defines files discovery in the repository. It can be either simple using wildcards or it can use full power of regular expressions.

The simple matching uses ** for component name and * for language, for example: **/*.po

The regular expression has to contain named groups component and language. For example: (?P<language>[^/]*)/(?P<component>[^-/]*)\.po

The import matches existing components based on files and adds the ones which do not exist. It does no changes to the already existing ones.

--name-template TEMPLATE¶

Customize the component’s name, using Django template syntax.

For example: Documentation: {{ component }}

--base-file-template TEMPLATE¶

Customize base file for monolingual translations.

For example: {{ component }}/res/values/string.xml

--new-base-template TEMPLATE¶

Customize base file for adding new translations.

For example: {{ component }}/ts/en.ts

--file-format FORMAT¶: You can also specify file format to use (see Supported formats), the default is autodetection.

--language-regex REGEX¶: You can specify language filtering (see Component configuration) by this parameter. It has to be valid regular expression.

--main-component¶: You can specify which component will be chosen as main - the one actually containing VCS repository.

--license NAME¶: Specify translation license.

--license-url URL¶: Specify translation license URL.

--vcs NAME¶: In case you need to specify version control system to use, you can do it here. The default version control is Git.

To give you some examples, let’s try importing two projects.

As first we import The Debian Handbook translations, where each language has separate folder with translations of each chapter:

./manage.py import_project \
    debian-handbook \
    git://anonscm.debian.org/debian-handbook/debian-handbook.git \
    squeeze/master \
    '*/**.po'

Another example can be Tanaguru tool, where we need to specify file format, base file template and has all components and translations located in single folder:

./manage.py import_project \
    --file-format=properties \
    --base-file-template=web-app/tgol-web-app/src/main/resources/i18n/%s-I18N.properties \
    tanaguru \
    https://github.com/Tanaguru/Tanaguru \
    master \
    web-app/tgol-web-app/src/main/resources/i18n/**-I18N_*.properties

Example of more complex parsing of filenames to get correct component and language out of file name like src/security/Numerous_security_holes_in_0.10.1.de.po:

./manage.py import_project \
    tails \
    git://git.tails.boum.org/tails master \
    'wiki/src/security/(?P<component>.*)\.(?P<language>[^.]*)\.po$'

Filtering only translations in chosen language:

./manage import_project \
    --language-regex '^(cs|sk)$' \
    weblate \
    https://github.com/WeblateOrg/weblate.git \
    'weblate/locale/*/LC_MESSAGES/**.po'

Ver también

More detailed examples can be found in the Starting with internationalization chapter, alternatively you might want to use import_json.

importuserdata¶

manage.py importuserdata <file.json>¶

Imports userdata from file created by dumpuserdata

importusers¶

manage.py importusers --check <file.json>¶

Imports users from JSON dump of Django auth_users database.

--check¶: With this option it will just check whether given file can be imported and report possible conflicts on usernames or emails.

You can dump users from existing Django installation using:

./manage.py dumpdata auth.User > users.json

install_addon¶

Nuevo en la versión 3.2.

manage.py install_addon --addon ADDON <project|project/component>¶

Installs addon to set of components.

--addon ADDON¶: Name of addon to install. For example weblate.gettext.customize.

--configuration CONFIG¶: JSON encoded configuration of an addon.

--update¶: Update existing addon configuration.

You can either define on which project or component to install addon (eg. weblate/master) or use --all to include all existing components.

For example installing Customize gettext output to all components:

./manage.py install_addon --addon weblate.gettext.customize --config '{"width": -1}' --update --all

Ver también

Addons

list_ignored_checks¶

manage.py list_ignored_checks¶

Lists most frequently ignored checks. This can be useful for tuning your setup, if users have to ignore too many of consistency checks.

list_languages¶

manage.py list_languages <locale>¶

Lists supported language in MediaWiki markup - language codes, English names and localized names.

This is used to generate <https://wiki.l10n.cz/Jazyky>.

list_memory¶

manage.py list_memory¶

Nuevo en la versión 2.20.

Lists contents of the Weblate Translation Memory.

--type {origin}¶: Type of information to list, defaults to listing used origins.

Ver también

Translation Memory, Backing up and moving Weblate, dump_memory

list_translators¶

manage.py list_translators <project|project/component>¶

Renders the list of translators by language for the given project:

[French]
Jean Dupont <jean.dupont@example.com>
[English]
John Doe <jd@exemple.com>

--language-code¶: Use language code instead of language name in output.

You can either define which project or component to use (eg. weblate/master) or use --all to list translators from all existing components.

list_versions¶

manage.py list_versions¶

Lists versions of Weblate dependencies.

loadpo¶

manage.py loadpo <project|project/component>¶

Reloads translations from disk (eg. in case you did some updates in VCS repository).

--force¶: Force update even if the files should be up to date.

--lang LANGUAGE¶: Limit processing to single language.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

Nota

You seldom need to invoke this, Weblate will automatically load changed files on VCS update. This is needed in case you manually change underlying Weblate VCS repository or in some special cases after upgrade.

lock_translation¶

manage.py lock_translation <project|project/component>¶

Locks given component for translating. This is useful in case you want to do some maintenance on underlying repository.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

Ver también

unlock_translation

optimize_memory¶

manage.py optimize_memory¶

Nuevo en la versión 3.2.

Optimizes translation memory storage.

--rebuild¶: The index will be completely rebuilt by dumping all content and creating it again. It is recommended to backup it prior to this operation.

Ver también

pushgit¶

manage.py pushgit <project|project/component>¶

Pushes committed changes to upstream VCS repository.

--force-commit¶: Force committing any pending changes prior to push.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

Nota

Weblate does push changes automatically if Push on commit in Component configuration is enabled, what is default.

rebuild_index¶

manage.py rebuild_index <project|project/component>¶

Rebuilds index for fulltext search. This might be lengthy operation if you have a huge set of translation strings.

--clean¶: Removes all words from database prior updating, this is implicit when called with --all.

--optimize¶: The index will not be processed again, only its content will be optimized (removing stale entries and merging possibly split index files).

Ver también

Fulltext search

unlock_translation¶

manage.py unlock_translation <project|project/component>¶

Unlocks a given component for translating. This is useful in case you want to do some maintenance on the underlying repository.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

Ver también

lock_translation

setupgroups¶

manage.py setupgroups¶

Configures default groups and optionally assigns all users to default group.

--no-privs-update¶: Disables update of existing groups (only adds new ones).

--no-projects-update¶: Prevents updates of groups for existing projects. This allows to add newly added groups to existing projects, see Per project access control.

Ver también

Access control

setuplang¶

manage.py setuplang¶

Setups list of languages (it has own list and all defined in translate-toolkit).

--no-update¶: Disables update of existing languages (only adds new ones).

updatechecks¶

manage.py updatechecks <project|project/component>¶

Updates all check for all strings. This could be useful only on upgrades which do major changes to checks.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

updategit¶

manage.py updategit <project|project/component>¶

Fetches remote VCS repositories and updates internal cache.

You can either define which project or component to update (eg. weblate/master) or use --all to update all existing components.

Nota

Usually it is better to configure hooks in the repository to trigger Notification hooks instead of regular polling by updategit.

Whiteboard messages¶

You can use whiteboard messages to give some information to your translators. The message can be site-wide or targeted to a translation component or language.

This can be useful for various things from announcing the purpose of the website to specifying targets for translations.

The whiteboard can currently be specified only in the admin interface:

The whiteboard messages are then shown based on specified context:

No context specified

Shown on dashboard (landing page).

Project specified

Shown on project, all its components and translations.

Component specified

Shown on component and all its translations.

Language specified

Shown on language overview and all translations in this language.

You can see how it looks on the language overview page:

And on the project page:

Component Lists¶

Weblate allows you to specify multiple lists of components. These will then appear as options on the user dashboard, and users can pick a list to be their default view when they log in. See Dashboard to learn more about this feature.

Distinto en la versión 2.20: The overview of all component lists status is also available on the dashboard.

The names and contents of component lists can be specified in the admin interface, in Component lists section. Each component list must have a name that is displayed to the user, and a slug that represents it in the URL.

Nota

Since version 2.13 you can also change the dashboard settings for the anonymous user in the admin interface, this will change what dashboard is visible to unauthenticated users.

Automatic component lists¶

Nuevo en la versión 2.13.

Additionally you can create Automatic component list assignment rules to automatically add components to the list based on their slug. This can be useful for maintaining component lists for large installations or in case you want to have component list with all components on your Weblate installation.

To create component list containing all components, you can simply define Automatic component list assignment with ^.*$ regular expression on both project and component as shown on following image:

Optional Weblate modules¶

Weblate comes with several optional modules which might be useful for your setup.

Git exporter¶

Nuevo en la versión 2.10.

The Git exporter provides you read only access to the underlying Git repository using HTTP.

Installation¶

To install, simply add weblate.gitexport to installed applications in settings.py:

INSTALLED_APPS += (
    'weblate.gitexport',
)

After installing, you need to migrate your database so that existing repositories are properly exported:

./manage.py migrate

Usage¶

The module automatically hooks into Weblate and sets exported repository URL in the Component configuration. The repositories are accessible under /git/ path of the Weblate, for example https://example.org/git/weblate/master/:

git clone 'https://example.org/git/weblate/master/'

Repositories are available anonymously unless Per project access control is enabled. In that case you need to authenticate using your API token (you can obtain it in your User profile):

git clone 'https://user:KEY@example.org/git/weblate/master/'

Billing¶

Nuevo en la versión 2.4.

Billing module is used on Hosted Weblate and is used to define billing plans, track invoices and usage limits.

Installation¶

To install, simply add weblate.billing to installed applications in settings.py:

INSTALLED_APPS += (
    'weblate.billing',
)

This module includes additional database structures, to have them installed you should run the database migration:

./manage.py migrate

Usage¶

After installation you can control billing in the admin interface. Users with billing enabled will get new Billing tab in their User profile.

The billing module additionally allows project admins to create new projects and components without being superusers (see Adding translation projects and components). This is possible when following conditions are met:

The billing is in it’s configured limits (any overusage results in blocking of project/component creation) and paid (if it’s price is non zero)
The user is admin of existing project with billing or user is owner of billing (the latter is necessary when creating new billing for users to be able to import new projects).

Upon project creation user is able to choose which billing should be charged for the project in case he has access to more of them.

Legal¶

Nuevo en la versión 2.15.

Legal module is used on Hosted Weblate and is used to provide required legal documents. It comes with blank documents and you are expected to provide following templates with the documents:

legal/documents/tos.html: Terms of service document
legal/documents/privacy.html: Privacy policy document
legal/documents/summary.html: Short overview of terms of service and privacy policy

Nota

You can find legal documents for the Hosted Weblate service in separate Git repository <https://github.com/WeblateOrg/hosted/tree/master/wlhosted/templates/legal/documents>.

Most likely these will not be directly usable for you, but you might want to use them as a starting point and adjust them to match your use case.

Installation¶

To install, simply add weblate.legal to installed applications in settings.py:

INSTALLED_APPS += (
    'weblate.legal',
)

# Optionals:

# Social auth pipeline to confirm TOS on registration/login
SOCIAL_AUTH_PIPELINE += (
    'weblate.legal.pipeline.tos_confirm',
)

# Middleware to enforce TOS confirmation of logged in users
MIDDLEWARE += [
    'weblate.legal.middleware.RequireTOSMiddleware',
]

This module includes additional database structures, to have them installed you should run the database migration:

./manage.py migrate

Now you should edit the legal documents to match your service. You can find them in the weblate/legal/templates/legal/ folder.

Usage¶

After installation the legal documents are shown in Weblate UI.

Avatars¶

Weblate comes with built in support for showing user avatars based on emails. This can be disabled using ENABLE_AVATARS. The avatars are downloaded and cached server side to reduce information leaks to the sites serving them.

Weblate currently supports single backend:

Gravatar

Ver también

Avatar caching, AVATAR_URL_PREFIX, ENABLE_AVATARS

Spam protection¶

Optionally Weblate can be protected against suggestion spamming by unauthenticated users through akismet.com service.

To enable this, you need to install akismet Python module and configure Akismet API key.

Ver también

AKISMET_API_KEY

Signing Git commits by GnuPG¶

Nuevo en la versión 3.1.

Weblate allows you to sign all commits by it’s GnuPG key. To configure this, you need to enable WEBLATE_GPG_IDENTITY. Weblate will generate GnuPG key when needed and will use it to sign all translation commits.

This feature needs GnuPG 2.1 or newer installed.

You can find the key in the DATA_DIR and the public key is shown on the about page:

Alternatively you can also import existing keys into Weblate, just set HOME=$DATA_DIR/home when invoking gpg.

Ver también

WEBLATE_GPG_IDENTITY

Rate limiting¶

Distinto en la versión 3.2: The rate limiting now accepts more fine grained configuration.

Several operations in Weblate are rate limited. At most RATELIMIT_ATTEMPTS attempts are allowed within RATELIMIT_WINDOW seconds. The user is then blocked for RATELIMIT_LOCKOUT. There are also per scope variants of those settings, eg. RATELIMIT_CONTACT_ATTEMPTS, see scopes below.

Following operations are subject to rate limiting:

Registration (REGISTRATION scope)
Sending message to admins (MESSAGE scope)
Password authentication on login (LOGIN scope)
Sitewide search (SEARCH scope)

Additionally if there are more than AUTH_LOCK_ATTEMPTS failed authentication attempts on one account, this account password authentication is disabled and it’s not possible to login until user asks for password reset.

IP address for rate limiting¶

The rate limiting is based on client IP address. This is obtained from HTTP headers and you will have to change configuration in the event Weblate is running behind reverse proxy to work it properly.

Ver también

IP_BEHIND_REVERSE_PROXY, IP_PROXY_HEADER, IP_PROXY_OFFSET

Customizing Weblate¶

Weblate can be extended or customized using standard Django and Python ways. Always please consider contributing changes upstream so that everybody can benefit from your additions. Including your changes in Weblate itself will also reduce your maintenance costs - code in Weblate is taken care of when changing internal interfaces or refactoring the code.

Advertencia

Neither internal interfaces or templates are considered as stable API. Please review your customizations on every upgrade, the interface or their semantics might change without notice.

Ver también

Contributing

Changing logo¶

To change logo you need to create simple Django app which will contain static files which you want to overwrite. Then you add it into INSTALLED_APPS:

INSTALLED_APPS = (
   # Weblate apps are here...

   # Add your customization as last
   'weblate_customization',
)

And then execute ./manage.py collectstatic --noinput, this will collect static files served to clients.

You can find example application for this at <https://github.com/WeblateOrg/customize-example>.

Ver también

Managing static files (e.g. images, JavaScript, CSS), Serving static files

Django admin interface¶

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 the wrench icon in top navigation:

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

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

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

Another section, Weblate languages holds language definitions, see Language definitions for more details.

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

Ver también

Project configuration

Bilingual components¶

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

Ver también

Component configuration, Bilingual and monolingual formats

Monolingual components¶

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

Ver también

Component configuration, Bilingual and monolingual formats

Translation workflows¶

Weblate can be configured to support several translation workflows. This document is not a complete listing of ways to configure Weblate, there are certainly more options. You can base another workflows on the most usual examples listed here.

Translation access¶

The Access control is not much discussed in the workflows as each of access control options can be applied to any workflows. Please consult that documentation for information how to manage access to translations.

In following chapters, any user means any user who has access to the translation. It can be any authenticated user if project is public or user having Translate permission on the project.

Translation states¶

Each translated string can be in following states:

Untranslated: Translation is empty, it might or not be stored in the file, depending on the file format.
Needs edit: Translation needs editing, this is usually result of source string change. The translation is stored in the file, depending on the file format it might be marked as needing edit (eg. fuzzy flag).
Waiting for review: Translation is done, but not reviewed. It is stored in the file as a valid translation.
Approved: Translation has been approved in the review. It can no longer be changed by translators, but only by reviewers. Translators can only add suggestions to it.
Suggestions: Suggestions are stored in Weblate only and not in the translation file.

Direct translation¶

This is most usual setup for smaller teams - anybody can directly translate. This is also default setup in Weblate.

Any user can edit translations.
Suggestions are optional way to suggest changes, when translators are not sure about the change.

Setting	Value	Note
Enable reviews	disabled	configured at project level
Enable suggestions	enabled	it is useful for users to be able suggest when they are not sure
Suggestion voting	disabled
Autoaccept suggestions	0
Translators group	Users	or Translate with access control
Reviewers group	N/A	not used

Peer review¶

With this workflow, anybody can add suggestions, however they need approval from additional member before it is accepted as a translation.

Any user can add suggestions
Any user can vote for suggestions
Suggestions become translations when they get given number of votes

Setting	Value	Note
Enable reviews	disabled	configured at project level
Enable suggestions	enabled
Suggestion voting	enabled
Autoaccept suggestions	1	you can set higher value to require more peer reviews
Translators group	Users	or Translate with access control
Reviewers group	N/A	not used, all translators review

Dedicated reviewers¶

Nuevo en la versión 2.18: The proper review workflow is supported since Weblate 2.18.

With dedicated reviewers you have two groups of users - one which can submit translations and one which reviews them. Review is there to ensure the translations are consistent and in a good quality.

Any user can edit non approved translations.
Reviewer can approve / unapproved strings.
Reviewer can edit all translations (including approved ones).
Suggestions are now also way to suggest changes for approved strings.

Setting	Value	Note
Enable reviews	enabled	configured at project level
Enable suggestions	enabled	it is useful for users to be able suggest when they are not sure
Suggestion voting	disabled
Autoaccept suggestions	0
Translators group	Users	or Translate with access control
Reviewers group	Reviewers	or Review with access control

Enabling reviews¶

The reviews can be enabled on project configuration, you can find the setting on bottom of Manage users page (to be found in the Manage/Users menu):

Nota

Depending on Weblate configuration, the setting might not be available to you. For example on Hosted Weblate this is not available for projects hosted for free.

Frequently Asked Questions¶

Configuration¶

How to create an automated workflow?¶

Weblate can handle all the translation things semi-automatically for you. If you give it push access to your repository, the translations can happen without interaction unless some merge conflict occurs.

Set up your git repository to tell Weblate whenever there is any change, see Notification hooks for information how to do it.
Set push URL at your Component configuration in Weblate, this will allow Weblate to push changes to your repository.
Enable push on commit on your Project configuration in Weblate, this will make Weblate push changes to your repository whenever they are committed at Weblate.

Ver también

Continuous translation, Avoiding merge conflicts

How to access repositories over SSH?¶

Please see Accessing repositories for information about setting up SSH keys.

How to fix merge conflicts in translations?¶

The merge conflicts happen from time to time when the translation file is changed in both Weblate and the upstream repository. You can usually avoid this by merging Weblate translations prior to doing some changes in the translation files (e.g. before executing msgmerge). Just tell Weblate to commit all pending translations (you can do it in the Repository maintenance in the Tools menu) and merge the repository (if automatic push is not enabled).

If you’ve already ran into the merge conflict, the easiest way is to solve all conflicts locally at your workstation - simply add Weblate as a remote repository, merge it into upstream and fix any conflicts. Once you push changes back, Weblate will be able to use the merged version without any other special actions.

# Commit all pending changes in Weblate, you can do this in the UI as well
wlc commit
# Lock translation in Weblate, again this can be done in the UI as well
wlc lock
# Add weblate as remote
git remote add weblate https://hosted.weblate.org/git/weblate/website/
# You might need to include credentials in some cases:
git remote add weblate https://username:APIKEY@hosted.weblate.org/git/weblate/website/

# Update weblate remote
git remote update weblate

# Merge Weblate changes
git merge weblate/master

# Resolve conflicts
edit ....
git add ...
...
git commit

# Push changes to upstream repository, Weblate will fetch merge from there
git push

# Open Weblate for translation
wlc unlock

If you’re using multiple branches in Weblate, you can work similarly on all branches:

# Add and update remotes
git remote add weblate-4.7 https://hosted.weblate.org/git/phpmyadmin/4-7/
git remote add weblate https://hosted.weblate.org/git/phpmyadmin/master/
git remote update weblate-4.7 weblate

# Merge QA_4_7 branch
git checkout QA_4_7
git merge weblate-4.7/QA_4_7
... # Resolve conflicts
git commit

# Merge master branch
git checkout master
git merge weblate/master
... # Resolve conflicts
git commit

# Push changes to upstream repository, Weblate will fetch merge from there
git push

In case of Gettext po files, there is a way to merge conflict in a semi-automatic way:

Get and keep local clone of the Weblate git repository. Also get a second fresh local clone of the upstream git repository (i. e. you need two copies of the upstream git repository: intact and working copy):

# Add remote
git remote add weblate /path/to/weblate/snapshot/

# Update weblate remote
git remote update weblate

# Merge Weblate changes
git merge weblate/master

# Resolve conflicts in the po files
for PO in `find . -name '*.po'` ; do
    msgcat --use-first /path/to/weblate/snapshot/$PO\
               /path/to/upstream/snapshot/$PO -o $PO.merge
    msgmerge --previous --lang=${PO%.po} $PO.merge domain.pot -o $PO
    rm $PO.merge
    git add $PO
done
git commit

# Push changes to upstream repository, Weblate will fetch merge from there
git push

Ver también

How to export the Git repository that Weblate uses?, Continuous translation, Avoiding merge conflicts

How do I translate several branches at once?¶

Weblate supports pushing translation changes within one Project configuration. For every Component configuration which has it enabled (the default behavior), the change made is automatically propagated to others. This way the translations are kept synchronized even if the branches themselves have already diverged quite a lot and it is not possible to simply merge translation changes between them.

Once you merge changes from Weblate, you might have to merge these branches (depending on your development workflow) discarding differences:

git merge -s ours origin/maintenance

How to export the Git repository that Weblate uses?¶

There is nothing special about the repository, it lives under the DATA_DIR directory and is named vcs/<project>/<component>/. If you have SSH access to this machine, you can use the repository directly.

For anonymous access you might want to run a git server and let it serve the repository to the outside world.

Alternatively you can use Git exporter inside Weblate to automate this.

What are the options for pushing changes back upstream?¶

This heavily depends on your setup, Weblate is quite flexible in this area. Here are examples of workflows used with Weblate:

Weblate automatically pushes and merges changes (see How to create an automated workflow?)
You manually tell Weblate to push (it needs push access to the upstream repository)
Somebody manually merges changes from the Weblate git repository into the upstream repository
Somebody rewrites history produced by Weblate (eg. by eliminating merge commits), merges changes and tells Weblate to reset the content on the upstream repository.

Of course you are free to mix all of these as you wish.

How can I limit Weblate access to translations only without exposing source code to it?¶

You can use git submodule for separating translations from source code while still having them under version control.

Create a repository with your translation files.

Add this as a submodule to your code:

git submodule add git@example.com:project-translations.git path/to/translations

Link Weblate to this repository, it no longer needs access to the repository with your source code.
You can update the main repository with translations from Weblate by:
```
git submodule update --remote path/to/translations
```

Please consult git submodule documentation for more details.

How can I check if my Weblate is configured properly?¶

Weblate includes a set of configuration checks which you can see in the admin interface, just follow the Performance report link in the admin interface or open the /admin/performance/ URL directly.

Why do links contain example.com as the domain?¶

Weblate uses Django’s sites framework and it defines the site name inside the database. You need to set the domain name to match your installation.

Ver también