Installation instructions


Django (>= 1.4)
Translate-toolkit (>= 1.9.0)
GitPython (>= 0.3)
Git (>= 1.0)
Django-registration (>= 0.8)
Database backend
Any database supported in Django will work, check their documentation for more details.


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


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


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


When using MySQL, don’t forget to create database with UTF-8 encoding:



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.


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


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

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

In case you want to run installation non interactively, you can use ./ syncdb –noinput and then create admin user using createadmin command.

You should also login to admin interface (on /admin/ URL) and adjust default site name to match your domain.


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

Production setup

For production setup you should do following adjustments:

Disable debug mode

Disable Django’s debug mode by:

DEBUG = False

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

See also


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:

    ('Your Name', ''),

See also


Set correct site name

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

Enable indexing offloading

Enable OFFLOAD_INDEXING to prevent locking issues and improve performance.

Use powerful database engine

Use powerful database engine (SQLite is usually not good enough for production environment), for example setup for MySQL:

    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'weblate',
        'USER': 'weblate',
        'PASSWORD': 'weblate',
        'HOST': '',
        'PORT': '',

Enable caching

If possible, use memcache from Django by adjusting CACHES config variable, for example:

    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '',

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:


Running server

Running Weblate is not different from running any other Django based application.

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

Serves media directory from Weblate.
Serves media files for Django admin interface (eg. /usr/share/pyshared/django/contrib/admin/media/).

Additionally you should setup rewrite rule to serve media/favicon.ico as favicon.ico.

Sample configuration for Lighttpd

The configuration for Lighttpd web server might look like following (available as examples/lighttpd.conf):

fastcgi.server = (
    "/weblate.fcgi" => (
        "main" => (
            "socket" => "/var/run/django/weblate.socket",
            "check-local" => "disable",
alias.url = (
    "/media" => "/var/lib/django/weblate/weblate/media/",
    "/static/admin" => "/usr/share/pyshared/django/contrib/admin/static/admin/",

url.rewrite-once = (
    "^(/*media.*)$" => "$1",
    "^(/*static.*)$" => "$1",
    "^/*favicon\.ico$" => "/media/favicon.ico",
    "^/*robots\.txt$" => "/media/robots.txt",
    "^(/.*)$" => "/weblate.fcgi$1",

expire.url                  = (
    "/media/" => "access 1 months",
    "/static/" => "access 1 months",
    "/favicon.ico" => "access 1 months",

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
WSGIPythonPath /usr/share/weblate
<VirtualHost *:80>

    DocumentRoot /usr/share/weblate/weblate/media/

    Alias /robots.txt /usr/share/weblate/weblate/media/robots.txt
    Alias /favicon.ico /usr/share/weblate/weblate/media/favicon.ico

    Alias /media/ /usr/share/weblate/weblate/media/
    Alias /doc/ /usr/share/doc/packages/weblate/html/
    Alias /static/admin /usr/lib/python2.7/site-packages/django/contrib/admin/static/admin/

    <Directory /usr/lib/python2.7/site-packages/django/contrib/admin/static/admin/>
        Order deny,allow
        Allow from all

    <Directory /usr/share/weblate/weblate/media/>
        Order deny,allow
        Allow from all

    <Directory /usr/share/doc/packages/weblate/html/>
        Order deny,allow
        Allow from all

    <Directory /usr/share/weblate/weblate/examples/>
        Order deny,allow
        Allow from all

    WSGIScriptAlias / /usr/share/weblate/weblate/
    WSGIPassAuthorization On

    <Directory /usr/share/weblate/weblate>
        Order deny,allow
        Allow from all


Running Weblate under path

Minimalistic configuration to serve Weblate under /weblate (you will need to include portions of above full configuration to allow access to the files). Again using mod_wsgi (also available as examples/apache-path.conf):

# Example Apache configuration for running Weblate under /weblate path

# Path to Weblate code
WSGIPythonPath /usr/share/weblate

# Path to Weblate WSGI handler
WSGIScriptAlias /weblate "/usr/share/weblate/weblate/"

# Aliases to serve media and static files
Alias /weblate/media/ /usr/share/weblate/weblate/media/
Alias /static/admin /usr/lib/python2.7/site-packages/django/contrib/admin/static/admin/

Additionally you will have to adjust weblate/

URL_PREFIX = '/weblate'


This is supported since Weblate 1.3.

Prebuilt appliance

Prebuilt appliance provides preconfigured Weblate running with MySQL database as backend and Apache as webserver. However it comes with standard set of passwords you will want to change:

Username Password Scope Description
root linux System Administrator account, use for local or SSH login
root   MySQL MySQL administrator
weblate weblate MySQL Account in MySQL database for storing Weblate data
admin admin Weblate Weblate/Django admin user

The appliance is built using SUSE Studio and is based on openSUSE 12.2.

You should also adjust some settings to match your environment, namely:


Generic upgrade instructions

Changed in version 1.2: Since version 1.2 the migration is done using South module, to upgrade to 1.2, please see Version specific instructions.

Before upgrading, please check current Requirements as they might have changed.

To upgrade database structure, you should run following commands:

./ syncdb
./ migrate

To upgrade default set of privileges definitions (optional), run:

./ setupgroups

To upgrade default set of language definitions (optional), run:

./ setuplang

Version specific instructions

Upgrade from 0.5 to 0.6

On upgrade to version 0.6 you should run ./ syncdb and ./ setupgroups –move to setup access control as described in installation section.

Upgrade from 0.6 to 0.7

On upgrade to version 0.7 you should run ./ syncdb to setup new tables and ./ rebuild_index to build index for fulltext search.

Upgrade from 0.7 to 0.8

On upgrade to version 0.8 you should run ./ syncdb to setup new tables, ./ setupgroups to update privileges setup and ./ rebuild_index to rebuild index for fulltext search.

Upgrade from 0.8 to 0.9

On upgrade to version 0.9 file structure has changed. You need to move repos and whoosh-index to weblate folder. Also running ./ syncdb, ./ setupgroups and ./ setuplang is recommended to get latest updates of privileges and language definitions.

Upgrade from 0.9 to 1.0

On upgrade to version 1.0 one field has been added to database, you need to invoke following SQL command to adjust it:

ALTER TABLE `trans_subproject` ADD `template` VARCHAR(200);

Upgrade from 1.0 (1.1) to 1.2

On upgrade to version 1.2, the migration procedure has changed. It now uses South for migrating database. To switch to this new migration schema, you need to run following commands:

./ syncdb
./ migrate weblate.trans 0001 --fake
./ migrate weblate.accounts 0001 --fake
./ migrate weblate.lang 0001 --fake

Also please note that there are several new requirements and version 0.8 of django-registration is now being required, see Requirements for more details.

Once you have done this, you can use Generic upgrade instructions.

Upgrade from 1.2 to 1.3

Since 1.3, is not shipped with Weblate, but only example settings as it is recommended to use it as new base for your setup.

Migrating from Pootle

As Weblate was originally written as replacement from Pootle, it is supported to migrate user accounts from Pootle. All you need to do is to copy auth_user table from Pootle, user profiles will be automatically created for users as they log in and they will be asked to update their settings.