Installation instructions

Hardware requirements

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on single host (Weblate, database and web server):

  • 1 GB of RAM memory
  • 2 CPU cores
  • 1 GB of storage space

The more memory you have, the better - it will be used for caching on all levels (filesystem, database and Weblate).

Примечание

The actual requirements for your installation heavily vary based on the size of translations managed by Weblate.

Software requirements

Python dependencies

Weblate is written in Python and supports Python 2.7, 3.4 or newer. The following dependencies can be installed using pip or your distribution packages:

Django (>= 1.11)
https://www.djangoproject.com/
siphashc (>= 0.8)
https://github.com/WeblateOrg/siphashc
translate-toolkit (>= 2.3.0)
http://toolkit.translatehouse.org/
Six (>= 1.7.0)
https://pypi.python.org/pypi/six
filelock (>= 3.0.1)
https://github.com/benediktschmitt/py-filelock
Mercurial (>= 2.8) (optional for Mercurial repositories support)
https://www.mercurial-scm.org/
social-auth-core (>= 1.3.0)
https://python-social-auth.readthedocs.io/
social-auth-app-django (>= 1.2.0)
https://python-social-auth.readthedocs.io/
django-appconf (>= 1.0)
https://github.com/django-compressor/django-appconf
Whoosh (>= 2.7.0)
https://bitbucket.org/mchaput/whoosh/wiki/Home
PIL or Pillow library
https://python-pillow.org/
lxml (>= 3.1.0)
http://lxml.de/
PyYaML (>= 3.0) (optional for YAML support)
http://pyyaml.org/wiki/PyYAML
defusedxml (>= 0.4)
https://bitbucket.org/tiran/defusedxml
dateutil
https://labix.org/python-dateutil
django_compressor (>= 2.1.1)
https://github.com/django-compressor/django-compressor
django-crispy-forms (>= 1.6.1)
https://django-crispy-forms.readthedocs.io/
Django REST Framework (>=3.8)
http://www.django-rest-framework.org/
user-agents (>= 1.1.0)
https://github.com/selwin/python-user-agents
libravatar (optional for federated avatar support)

You need to additionally install pydns (on Python 2) or py3dns (on Python 3) to make libravatar work.

https://pypi.python.org/pypi/pyLibravatar

pyuca (>= 1.1) (optional for proper sorting of strings)
https://github.com/jtauber/pyuca
Babel (optional for Android resources support)
http://babel.pocoo.org/
phply (optional for PHP support)
https://github.com/viraptor/phply
Database backend
Any database supported in Django will work, see Database setup for Weblate and backends documentation for more details.
pytz (optional, but recommended by Django)
https://pypi.python.org/pypi/pytz/
python-bidi (optional for proper rendering of badges in RTL languages)
https://github.com/MeirKriheli/python-bidi
tesserocr (>= 2.0.0) (optional for screenshots OCR)
https://github.com/sirfz/tesserocr
akismet (>= 1.0) (optional for suggestion spam protection)
https://github.com/ubernostrum/akismet
PyYAML (>= 3.0) (optional for YAML files)
https://pyyaml.org/
python-Levenshtein (recommended for performance)
https://github.com/ztane/python-Levenshtein/

Other system requirements

The following dependencies have to be installed on the system:

Git (>= 1.6)
https://git-scm.com/
hub (optional for sending pull requests to GitHub)
https://hub.github.com/
git-review (optional for Gerrit support)
https://pypi.python.org/pypi/git-review
git-svn (>= 2.10.0) (optional for Subversion support)
https://git-scm.com/docs/git-svn
tesseract and it’s data (optional for screenshots OCR)
https://github.com/tesseract-ocr/tesseract

Compile time dependencies

To compile some of the Python dependencies you might need to install their dependencies. This depends on how you install them, so please consult individual packages for documentation. You won’t need those if using prebuilt Wheels while installing using pip or when you use distribution packages.

Installing Weblate

Choose an installation method that best fits your environment.

First choices include complete setup without relying on your system libraries:

You can also install Weblate directly on your system either fully using distribution packages (currently available for openSUSE only) or mixed setup.

Choose installation method:

And install dependencies according your platform:

Installing in virtualenv

This is recommended method if you don’t want to dig into details. This will create separate Python environment for Weblate, possibly duplicating some system Python libraries.

  1. Install development files for libraries we will use during building Python modules:

    # Debian/Ubuntu:
    apt install libxml2-dev libxslt-dev libfreetype6-dev libjpeg-dev libz-dev libyaml-dev python-dev
    
    # openSUSE/SLES:
    zypper install libxslt-devel libxml2-devel freetype-devel libjpeg-devel zlib-devel libyaml-devel python-devel
    
    # Fedora/RHEL/CentOS:
    dnf install libxslt-devel libxml2-devel freetype-devel libjpeg-devel zlib-devel libyaml-devel python-devel
    
  2. Install pip and virtualenv. Usually they are shipped by your distribution or with Python:

    # Debian/Ubuntu:
    apt-get install python-pip python-virtualenv
    
    # openSUSE/SLES:
    zypper install python-pip python-virtualenv
    
    # Fedora/RHEL/CentOS:
    dnf install python-pip python-virtualenv
    
  3. Create and activate virtualenv for Weblate (the path in /tmp is really just an example, you rather want something permanent):

    virtualenv /tmp/weblate
    . /tmp/weblate/bin/activate
    
  4. Install Weblate including all dependencies, you can also use pip to install optional dependecies:

    pip install Weblate
    # Optional deps
    pip install pytz python-bidi PyYaML Babel pyuca pylibravatar pydns
    
  5. Create your settings (in our example it would be in /tmp/weblate/lib/python2.7/site-packages/weblate/settings.py based on the settings_example.py in same directory).

  6. You can now run Weblate commands using weblate command, see Management commands.

  7. To run webserver, use the wsgi wrapper installed with Weblate (in our case it is /tmp/weblate/lib/python2.7/site-packages/weblate/wsgi.py). Don’t forget to set Python search path to your virtualenv as well (for example using virtualenv = /tmp/weblate in uwsgi).

Installing Weblate from Git

You can also run the latest version from Git. It is maintained stable and production ready. You can usually find it running on Hosted Weblate.

To get latest sources using Git use:

git clone https://github.com/WeblateOrg/weblate.git

Примечание

If you are running a version from Git, you should also regenerate locale files every time you are upgrading. You can do this by invoking script ./scripts/generate-locales.

Installing Weblate by pip

If you decide to install Weblate using pip installer, you will notice some differences. Most importantly the command line interface is installed to the system path as weblate instead of ./manage.py as used in this documentation. Also when invoking this command, you will have to specify settings, either by environment variable DJANGO_SETTINGS or on the command line, for example:

weblate --settings=yourproject.settings migrate

Requirements on Debian or Ubuntu

On recent Debian or Ubuntu, most of requirements are already packaged, to install them you can use apt-get:

apt-get install python-pip python-django translate-toolkit \
    python-whoosh python-pil python-libravatar \
    python-babel git mercurial \
    python-django-compressor python-django-crispy-forms \
    python-djangorestframework python-dateutil

# Optional packages for database backend:

# For PostgreSQL
apt-get install python-psycopg2
# For MySQL on Ubuntu (if using Ubuntu package for Django)
apt-get install python-pymysql
# For MySQL on Debian (or Ubuntu if using upstream Django packages)
apt-get install python-mysqldb

On older versions, some required dependencies are missing or outdated, so you need to install several Python modules manually using pip:

# Dependencies for python-social-auth
apt-get install python-requests-oauthlib python-six python-openid

# Social auth
pip install social-auth-core
pip install social-auth-app-django

# In case your distribution has python-django older than 1.9
pip install Django

# In case python-django-crispy-forms package is missing
pip install django-crispy-forms

# In case python-whoosh package is misssing or older than 2.7
pip install Whoosh

# In case your python-django-compressor package is missing,
# try installing it by older name or using pip:
apt-get install python-compressor
pip install django_compressor

# Optional for OCR support
apt-get install tesseract-ocr libtesseract-dev libleptonica-dev cython
pip install tesserocr

For proper sorting of a Unicode strings, it is recommended to install pyuca:

pip install pyuca

Depending on how you intend to run Weblate and what you already have installed, you might need additional components:

# Web server option 1: nginx and uwsgi
apt-get install nginx uwsgi uwsgi-plugin-python

# Web server option 2: Apache with mod_wsgi
apt-get install apache2 libapache2-mod-wsgi

# Caching backend: redis
apt-get install redis-server

# Database option 1: postgresql
apt-get install postgresql

# Database option 2: mariadb
apt-get install mariadb-server

# Database option 3: mysql
apt-get install mysql-server

# SMTP server
apt-get install exim4

# GitHub PR support: hub
# See https://hub.github.com/

Requirements on openSUSE

Most of requirements are available either directly in openSUSE or in devel:languages:python repository:

zypper install python-Django translate-toolkit \
    python-Whoosh python-Pillow \
    python-social-auth-core python-social-auth-app-django \
    python-babel Git mercurial python-pyuca \
    python-dateutil

# Optional for database backend
zypper install python-psycopg2      # For PostgreSQL
zypper install python-MySQL-python  # For MySQL

Depending on how you intend to run Weblate and what you already have installed, you might need additional components:

# Web server option 1: nginx and uwsgi
zypper install nginx uwsgi uwsgi-plugin-python

# Web server option 2: Apache with mod_wsgi
zypper install apache2 apache2-mod_wsgi

# Caching backend: redis
zypper install redis-server

# Database option 1: postgresql
zypper install postgresql

# Database option 2: mariadb
zypper install mariadb

# Database option 3: mysql
zypper install mysql

# SMTP server
zypper install postfix

# GitHub PR support: hub
# See https://hub.github.com/

Requirements on OSX

If your python was not installed using brew, make sure you have this in your .bash_profile file or executed somehow:

export PYTHONPATH="/usr/local/lib/python2.7/site-packages:$PYTHONPATH"

This configuration makes the installed libraries available to Python.

Requirements using pip installer

Most requirements can be also installed using pip installer:

pip install -r requirements.txt

For building some of the extensions devel files for several libraries are required, see Installing in virtualenv for instructions how to install these.

All optional dependencies (see above) can be installed using:

pip install -r requirements-optional.txt

Filesystem permissions

The Weblate process needs to be able to read and write to the directory where it keeps data - DATA_DIR.

The default configuration places them in the same tree as Weblate sources, however you might prefer to move these to better location such as /var/lib/weblate.

Weblate tries to create these directories automatically, but it will fail when it does not have permissions to do so.

You should also take care when running Management commands, as they should be run under the same user as Weblate itself is running, otherwise permissions on some files might be wrong.

См.также

Serving static files

Database setup for Weblate

It is recommended to run Weblate on some database server. Using SQLite backend is really suitable only for testing purposes.

PostgreSQL

PostgreSQL is usually the best choice for Django based sites. It’s the reference database used for implementing Django database layer.

См.также

PostgreSQL notes

Creating database in PostgreSQL

It is usually good idea to run Weblate in a separate database and separate user account:

# If PostgreSQL was not installed before, set the master password
sudo -u postgres psql postgres -c "\password postgres"

# Create database user called "weblate"
sudo -u postgres createuser -D -P weblate

# Create database "weblate" owned by "weblate"
sudo -u postgres createdb -O weblate weblate

Configuring Weblate to use PostgreSQL

The settings.py snippet for PostgreSQL:

DATABASES = {
    'default': {
        # Database engine
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        # Database name
        'NAME': 'weblate',
        # Database user
        'USER': 'weblate',
        # Database password
        'PASSWORD': 'password',
        # Set to empty string for localhost
        'HOST': 'database.example.com',
        # Set to empty string for default
        'PORT': '',
    }
}

MySQL or MariaDB

MySQL or MariaDB are quite good choices to run Weblate. However when using MySQL you might hit some problems caused by it.

См.также

MySQL notes

Unicode issues in MySQL

MySQL by default uses something called utf8, what can not store all Unicode characters, only those who fit into three bytes in utf-8 encoding. In case you’re using emojis or some other higher Unicode symbols you might hit errors when saving such data. Depending on MySQL and Python bindings version, the error might look like:

  • OperationalError: (1366, "Incorrect string value: '\\xF0\\xA8\\xAB\\xA1' for column 'target' at row 1")
  • UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128)

To solve this, you need to change your database to use utf8mb4 (what is again subset of Unicode, but this time which can be stored in four bytes in utf-8 encoding, thus covering all chars currently defined in Unicode).

This can be achieved at database creation time by creating it with this character set (see Creating database in MySQL) and specifying the character set in connection settings (see Configuring Weblate to use MySQL).

In case you have existing database, you can change it to utf8mb4 by, but this won’t change collation of existing fields:

ALTER DATABASE weblate CHARACTER SET utf8mb4;

Transaction locking

MySQL by default uses has different transaction locking scheme than other databases and in case you see errors like Deadlock found when trying to get lock; try restarting transaction it might be good idea to enable STRICT_TRANS_TABLES mode in MySQL. This can be done in the server configuration file (usually /etc/mysql/my.cnf on Linux):

[mysqld]
sql-mode=STRICT_TRANS_TABLES

См.также

Setting sql_mode

Creating database in MySQL

Create weblate user to access the weblate database:

# Grant all privileges to  weblate user
GRANT ALL PRIVILEGES ON weblate.* TO 'weblate'@'localhost'  IDENTIFIED BY 'password';

# Create database on MySQL >= 5.7.7
CREATE DATABASE weblate CHARACTER SET utf8mb4;

# Use utf8 for older versions
# CREATE DATABASE weblate CHARACTER SET utf8;

Configuring Weblate to use MySQL

The settings.py snippet for MySQL:

DATABASES = {
    'default': {
        # Database engine
        'ENGINE': 'django.db.backends.mysql',
        # Database name
        'NAME': 'weblate',
        # Database user
        'USER': 'weblate',
        # Database password
        'PASSWORD': 'password',
        # Set to empty string for localhost
        'HOST': 'database.example.com',
        # Set to empty string for default
        'PORT': '',
        # Additional database options
        'OPTIONS': {
            # In case of older MySQL server which has default MariaDB
            # 'init_command': 'SET storage_engine=INNODB',
            # If your server supports it, see Unicode issues above
           'charset': 'utf8mb4',
        }

    }
}

Other configurations

Configuring outgoing mail

Weblate sends out emails on various occasions - for account activation and on various notifications configured by users. For this it needs access to the SMTP server, which will handle this.

The mail server setup is configured using settings EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_HOST_USER and EMAIL_PORT. Their names are quite self-explanatory, but you can find out more information in the Django documentation.

Примечание

You can verify whether outgoing mail is working correctly by using sendtestemail management command.

Installation

См.также

Sample configuration

Copy weblate/settings_example.py to weblate/settings.py and adjust it to match your setup. You will probably want to adjust the following options:

ADMINS

List of site administrators to receive notifications when something goes wrong, for example notifications on failed merge or Django errors.

См.также

ADMINS

ALLOWED_HOSTS

If you are running Django 1.5 or newer, you need to set this to list of hosts your site is supposed to serve. For example:

ALLOWED_HOSTS = ['demo.weblate.org']

См.также

ALLOWED_HOSTS

SESSION_ENGINE

Configure how your sessions will be stored. In case you keep default database backed engine you should schedule ./manage.py clearsessions to remove stale session data from the database.

DATABASES

Connectivity to database server, please check Django’s documentation for more details.

DEBUG

Disable this for production server. With debug mode enabled, Django will show backtraces in case of error to users, when you disable it, errors will go by email to ADMINS (see above).

Debug mode also slows down Weblate as Django stores much more information internally in this case.

См.также

DEBUG,

DEFAULT_FROM_EMAIL

Email sender address for outgoing email, for example registration emails.

См.также

DEFAULT_FROM_EMAIL,

SECRET_KEY

Key used by Django to sign some information in cookies, see Django secret key for more information.

SERVER_EMAIL

Email used as sender address for sending emails to administrator, for example notifications on failed merge.

См.также

SERVER_EMAIL

Filling up the database

After your configuration is ready, you can run ./manage.py migrate to create the database structure. Now you should be able to create translation projects using the admin interface.

In case you want to run installation non interactively, you can use ./manage.py migrate --noinput and then create admin user using createadmin command.

You should also login to admin interface (on /admin/ URL) and adjust the default site name to match your domain by clicking on Sites and there changing the example.com record to match your real domain name.

Once you are done, you should also check Performance report in the admin interface which will give you hints for non optimal configuration on your site.

Production setup

For production setup you should do following adjustments.

См.также

Deployment checklist

Disable debug mode

Disable Django’s debug mode (DEBUG) by:

DEBUG = False

With debug mode Django stores all executed queries and shows users backtraces of errors which is not desired in production setup.

См.также

Installation

Properly configure admins

Set correct admin addresses to ADMINS setting for defining who will receive mail in case something goes wrong on the server, for example:

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

См.также

Installation

Set correct site name

Adjust site name in admin interface, otherwise links in RSS or registration emails will not work.

Please open the admin interface and edit default site name and domain under the Sites › Sites (or you can do that directly at /admin/sites/site/1/ URL under your Weblate installation). You have to change the Domain name to match your setup.

Примечание

This setting should contain only the domain name. For configuring protocol (enabling HTTPS) use ENABLE_HTTPS and for changing URL use URL_PREFIX.

Alternatively, you can set the site name from command line using changesite. For example, when using built in server:

./manage.py changesite --set-name 127.0.0.1:8000

For production site, you want something like:

./manage.py changesite --set-name weblate.example.com

Enable indexing offloading

Enable OFFLOAD_INDEXING to prevent locking issues and improve performance. Don’t forget to schedule indexing as a background job to keep the index up to date.

Use powerful database engine

Use a powerful database engine (SQLite is usually not good enough for production environment), see Database setup for Weblate for more information.

Enable caching

If possible, use redis from Django by adjusting CACHES configuration variable, for example:

CACHES = {
    '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',
        }
    }
}

Alternatively you can also use memcached:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
    }
}

Avatar caching

In addition to caching of Django, Weblate performs caching of avatars. It is recommended to use separate, file backed cache for this purpose:

CACHES = {
    'default': {
        # Default caching backend setup, see above
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
            'PARSER_CLASS': 'redis.connection.HiredisParser',
        }
    },
    'avatar': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': os.path.join(DATA_DIR, 'avatar-cache'),
        'TIMEOUT': 604800,
        'OPTIONS': {
            'MAX_ENTRIES': 1000,
        },
    }

Configure email addresses

Weblate needs to send out emails on several occasions and these emails should have correct sender address, please configure SERVER_EMAIL and DEFAULT_FROM_EMAIL to match your environment, for example:

SERVER_EMAIL = 'admin@example.org'
DEFAULT_FROM_EMAIL = 'weblate@example.org'

Allowed hosts setup

Django 1.5 and newer require ALLOWED_HOSTS to hold a list of domain names your site is allowed to serve, having it empty will block any request.

См.также

ALLOWED_HOSTS

Federated avatar support

By default, Weblate relies on <https://www.libravatar.org/> for avatars. When you install pyLibavatar, you will get proper support for federated avatars.

pyuca library

pyuca library is optionally used by Weblate to sort Unicode strings. This way language names are properly sorted even in non-ASCII languages like Japanese, Chinese or Arabic or for languages with accented letters.

Django secret key

The SECRET_KEY setting is used by Django to sign cookies and you should really generate your own value rather than using the one coming from example setup.

You can generate new key using examples/generate-secret-key shipped with Weblate.

См.также

SECRET_KEY

Static files

If you see purely designed admin interface, the CSS files required for it are not loaded. This is usually if you are running in non-debug mode and have not configured your web server to serve them. Recommended setup is described in the Serving static files chapter.

Home directory

Изменено в версии 2.1: This is no longer required, Weblate now stores all its data in DATA_DIR.

The home directory for the user which is running Weblate should be existing and writable by this user. This is especially needed if you want to use SSH to access private repositories, but Git might need to access this directory as well (depends on the Git version you use).

You can change the directory used by Weblate in settings.py, for example to set it to configuration directory under Weblate tree:

os.environ['HOME'] = os.path.join(BASE_DIR, 'configuration')

Примечание

On Linux and other UNIX like systems, the path to user’s home directory is defined in /etc/passwd. Many distributions default to non writable directory for users used for serving web content (such as apache, www-data or wwwrun, so you either have to run Weblate under a different user or change this setting.

См.также

Accessing repositories

Template loading

It is recommended to use cached template loader for Django. It caches parsed templates and avoids the need to do the parsing with every single request. You can configure it using the following snippet (the loaders setting is important here):

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            os.path.join(BASE_DIR, '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',
                ]),
            ],
        },
    },
]

Running maintenance tasks

For optimal performance, it is good idea to run some maintenance tasks in the background.

On a Unix-likesystem, this can be scheduled using cron:

# Fulltext index updates
*/5 * * * * cd /usr/share/weblate/; ./manage.py update_index

# Cleanup stale objects
@daily cd /usr/share/weblate/; ./manage.py cleanuptrans

# Commit pending changes after 96 hours
@hourly cd /usr/share/weblate/; ./manage.py commit_pending --all --age=96 --verbosity=0

Running server

Running Weblate is not different from running any other Django based application. Django is usually executed as uwsgi or fcgi (see examples for different webservers below).

For testing purposes, you can use the Django built-in web server:

./manage.py runserver

Предупреждение

Do not use this in production as this has severe performance limitations.

Serving static files

Изменено в версии 2.4: Prior to version 2.4 Weblate didn’t properly use Django static files framework and the setup was more complex.

Django needs to collect its static files to a single directory. To do so, execute ./manage.py collectstatic --noinput. This will copy the static files into directory specified by STATIC_ROOT setting (this defaults to static directory inside DATA_DIR).

It is recommended to serve static files directly by your web server, you should use that for following paths:

/static/
Serves static files for Weblate and admin interface (from defined by STATIC_ROOT).
/media/
Used for user media uploads (eg. screenshots).
/favicon.ico
Should be rewritten to rewrite rule to serve /static/favicon.ico
/robots.txt
Should be rewritten to rewrite rule to serve /static/robots.txt

Content security policy

Default Weblate configuration enables weblate.middleware.SecurityMiddleware middleware which sets security related HTTP headers like Content-Security-Policy or X-XSS-Protection. These are set to work with Weblate and it’s configuration, but this might clash with your customization. If that is your case, it is recommended to disable this middleware and set these headers manually.

Sample configuration for Apache

Following configuration runs Weblate as WSGI, you need to have enabled mod_wsgi (available as examples/apache.conf):

#
# VirtualHost for weblate
#
# This example assumes Weblate is installed in /usr/share/weblate
#
# If using virtualenv, you need to add it to search path as well:
# WSGIPythonPath /usr/share/weblate:/path/to/your/venv/lib/python2.7/site-packages
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/robots.txt
    Alias /robots.txt /var/lib/weblate/static/robots.txt
    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /var/lib/weblate/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /var/lib/weblate/static/
    <Directory /var/lib/weblate/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /var/lib/weblate/media/
    <Directory /var/lib/weblate/media/>
        Require all granted
    </Directory>

    WSGIDaemonProcess weblate.example.org python-path=/usr/share/weblate
    WSGIProcessGroup weblate.example.org
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /usr/share/weblate/weblate/wsgi.py process-group=weblate.example.org
    WSGIPassAuthorization On

    <Directory /usr/share/weblate/weblate>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

This configuration is for Apache 2.4 and later. For earlier versions of Apache, replace Require all granted with Allow from all.

Sample configuration for Apache and gunicorn

Following configuration runs Weblate in gunicorn and Apache 2.4 (available as examples/apache.gunicorn.conf):

#
# VirtualHost for weblate using gunicorn on localhost:8000
#
# This example assumes Weblate is installed in /usr/share/weblate
#
#

<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/robots.txt
    Alias /robots.txt /var/lib/weblate/static/robots.txt
    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /var/lib/weblate/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /var/lib/weblate/static/
    <Directory /var/lib/weblate/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /var/lib/weblate/media/
    <Directory /var/lib/weblate/media/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /robots.txt !
    ProxyPass /favicon.ico !
    ProxyPass /static/ !
    ProxyPass /media/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

Sample configuration for nginx and uwsgi

The following configuration runs Weblate as uwsgi under nginx webserver.

Configuration for nginx (also available as examples/weblate.nginx.conf):

server {
    listen 80;
    server_name weblate;
    root /usr/share/weblate;

    location ~ ^/favicon.ico$ {
        # DATA_DIR/static/favicon.ico
        alias /var/lib/weblate/static/favicon.ico;
        expires 30d;
    }

    location ~ ^/robots.txt$ {
        # DATA_DIR/static/robots.txt
        alias /var/lib/weblate/static/robots.txt;
        expires 30d;
    }

    location /static/ {
        # DATA_DIR/static/
        alias /var/lib/weblate/static/;
        expires 30d;
    }

    location /media/ {
        # DATA_DIR/media/
        alias /var/lib/weblate/media/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

Configuration for uwsgi (also available as examples/weblate.uwsgi.ini):

[uwsgi]
plugins       = python
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /path/to/weblate/weblate/wsgi.py
python-path   = /path/to/weblate
# In case you're using virtualenv uncomment this:
# virtualenv = /path/to/weblate/virtualenv
# Needed for OAuth/OpenID
buffer-size   = 8192
# Increase number of workers for heavily loaded sites
#workers       = 6
# Needed for background processing
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022

Running Weblate under path

Изменено в версии 1.3: This is supported since Weblate 1.3.

Sample Apache configuration to serve Weblate under /weblate. Again using mod_wsgi (also available as examples/apache-path.conf):

# Example Apache configuration for running Weblate under /weblate path

WSGIPythonPath /usr/share/weblate
# If using virtualenv, you need to add it to search path as well:
# WSGIPythonPath /usr/share/weblate:/path/to/your/venv/lib/python2.7/site-packages
<VirtualHost *:80>
    ServerAdmin admin@image.weblate.org
    ServerName image.weblate.org

    # DATA_DIR/static/robots.txt
    Alias /weblate/robots.txt /var/lib/weblate/static/robots.txt
    # DATA_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /var/lib/weblate/static/favicon.ico

    # DATA_DIR/static/
    Alias /weblate/static/ /var/lib/weblate/static/
    <Directory /var/lib/weblate/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /weblate/media/ /var/lib/weblate/media/
    <Directory /var/lib/weblate/media/>
        Require all granted
    </Directory>

    WSGIScriptAlias /weblate /usr/share/weblate/weblate/wsgi.py
    WSGIPassAuthorization On

    <Directory /usr/share/weblate/weblate>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Additionally, you will have to adjust weblate/settings.py:

URL_PREFIX = '/weblate'

Monitoring Weblate

Weblate provides /healthz/ URL to be used in simple health checks, for example using Kubernetes.

Collecting error reports

It is good idea to collect errors from any Django application in structured way and Weblate is not an exception from this. You might find several services providing this, for example:

Rollbar

Weblate has built in support for Rollbar. To use it it’s enough to follow instructions for Rollbar notifier for Python.

In short, you need to adjust settings.py:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # ... other middleware classes ...
    'rollbar.contrib.django.middleware.RollbarNotifierMiddleware',
]

# Configure client access
ROLLBAR = {
    'access_token': 'POST_SERVER_ITEM_ACCESS_TOKEN',
    'client_token': 'POST_CLIENT_ITEM_ACCESS_TOKEN',
    'environment': 'development' if DEBUG else 'production',
    'branch': 'master',
    'root': '/absolute/path/to/code/root',
}

Everything else is integrated automatically, you will now collect both server and client side errors.

Migrating Weblate to another server

Migrating Weblate to another server should be pretty easy, however it stores data in few locations which you should migrate carefully. The best approach is to stop migrated Weblate for the migration.

Migrating database

Depending on your database backend, you might have several options to migrate the database. The most straightforward one is to dump the database on one server and import it on the new one. Alternatively you can use replication in case your database supports it.

The best approach is to use database native tools as they are usually the most effective (eg. mysqldump or pg_dump). If you want to migrate between different databases, the only option might be to use Django management to dump and import the database:

# Export current data
./manage.py dumpdata > /tmp/weblate.dump
# Import dump
./manage.py loaddata /tmp/weblate.dump

Migrating VCS repositories

The VCS repositories stored under DATA_DIR need to be migrated as well. You can simply copy them or use rsync to do the migration more effectively.

Migrating fulltext index

For the fulltext index (stored in DATA_DIR) it is better not to migrate it, but rather to generate a fresh one using rebuild_index.

Other notes

Don’t forget to move other services which Weblate might have been using like redis, memcached, cron jobs or custom authentication backends.