If you want to run Weblate with Python 2.6, you should also install following modules:
On Debian or Ubuntu, all requirements are already packaged, to install them you can use apt-get:
apt-get install python-django translate-toolkit python-git python-django-registration \
python-whoosh python-imaging python-django-south python-libravatar python-pyicu
# Optional for database backend
apt-get install python-mysqldb # For MySQL
apt-get install python-psycopg2 # For PostgreSQL
All requirements are available either directly in openSUSE or in devel:languages:python repository:
zypper install python-django python-django-registration translate-toolkit python-GitPython \
python-whoosh python-imaging python-South
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 make available the installed libraries to python
Most requirements can be also installed using pip installer:
pip install -r requirements.txt
Also you will need header files for libxml2 and libxslt to compile some of the required Python modules.
On Debian or Ubuntu you can install them using:
apt-get install libxml2-dev libxslt-dev
On openSUSE or SLES you can install them using:
zypper install libxslt-devel libxml2-devel
Weblate process needs to be able to read and write to two directories where it keeps data. The GIT_ROOT is used for storing Git repositories and WHOOSH_INDEX is used for fulltext search data.
The default configuration places them in 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 same user as Weblate itself is running, otherwise permissions on some files might be wrong.
Copy weblate/settings_example.py to weblate/settings.py and adjust it to match your setup. You will probably want to adjust following options:
ADMINS
List of site administrators to receive notifications when something goes wrong, for example notifications on failed merge or Django errors.
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']
DATABASES
Connectivity to database server, please check Django’s documentation for more details.
Note
When using MySQL, don’t forget to create database with UTF-8 encoding:
CREATE DATABASE <dbname> CHARACTER SET utf8;
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.
DEFAULT_FROM_EMAIL
Email sender address for outgoing email, for example registration emails.
See also
SECRET_KEY
Key used by Django to sign some information in cookies. If you don’t change this, the cookies can be spoofed by anyone.
SERVER_EMAIL
Email used as sender address for sending emails to administrator, for example notifications on failed merge.
See also
After your configuration is ready, you can run ./manage.py syncdb and ./manage.py 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 ./manage.py 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.
Note
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.
For production setup you should do following adjustments:
Disable Django’s debug mode by:
DEBUG = False
With debug mode Django stores all executed queries and shows users backtraces of errors what is not desired in production setup.
See also
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'),
)
See also
Adjust site name in admin interface, otherwise links in RSS or registration emails will not work.
Enable OFFLOAD_INDEXING to prevent locking issues and improve performance. Don’t forget to schedule indexing in background job to keep the index up to date.
See also
Use powerful database engine (SQLite is usually not good enough for production environment), for example setup for MySQL:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'weblate',
'USER': 'weblate',
'PASSWORD': 'weblate',
'HOST': '127.0.0.1',
'PORT': '',
}
}
See also
If possible, use memcache from Django by adjusting CACHES config variable, for example:
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
See also
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'
Django 1.5 and newer require ALLOWED_HOSTS to hold list of domain names your site is allowed to serve, having it empty will block any request.
By default, Weblate relies on <https://www.libravatar.org/> for avatars. When you install pyLibavatar, you will get proper support for federated avatars.
PyICU 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.
The SECRET_KEY setting is used by Django to sign cookies and you should really use own value rather than using the one coming from example setup.
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 webserver to serve them. Recommended setup is described in the Running server chapter.
See also
The home directory for 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.
Note
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 different user or change this setting.
See also
Running Weblate is not different from running any other Django based application.
It is recommended to serve static files directly by your web server, you should use that for following paths:
Additionally you should setup rewrite rule to serve media/favicon.ico as favicon.ico.
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",
)
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>
ServerAdmin admin@image.weblate.org
ServerName image.weblate.org
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>
<Directory /usr/share/weblate/weblate/media/>
Order deny,allow
Allow from all
</Directory>
<Directory /usr/share/doc/packages/weblate/html/>
Order deny,allow
Allow from all
</Directory>
<Directory /usr/share/weblate/weblate/examples/>
Order deny,allow
Allow from all
</Directory>
WSGIScriptAlias / /usr/share/weblate/weblate/wsgi.py
WSGIPassAuthorization On
<Directory /usr/share/weblate/weblate>
<Files wsgi.py>
Order deny,allow
Allow from all
</Files>
</Directory>
</VirtualHost>
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/wsgi.py"
# 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/settings.py:
URL_PREFIX = '/weblate'
Note
This is supported since Weblate 1.3.
By default Weblate uses Django built-in user database. Thanks to this, you can also import user database from other Django based projects (see Migrating from Pootle).
But Django can be configured to authenticate against other means as well. Currently you have to register and confirm your email even when using other authentication backend.
LDAP authentication can be best achieved using django-auth-ldap package. You can install it by usual means:
# Using PyPI
pip install django-auth-ldap
# Using apt-get
apt-get install python-django-auth-ldap
Once you have the package installed, you can hook it to 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',
'django.contrib.auth.backends.ModelBackend',
)
# 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 different DN
# like:
# AUTH_LDAP_USER_DN_TEMPLATE = 'ou=users,dc=example,dc=com'
# List of attributes to import from LDAP on login
AUTH_LDAP_USER_ATTR_MAP = {
'first_name': 'givenName',
'last_name': 'sn',
'email': 'mail',
}
Prebuilt appliance provides preconfigured Weblate running with MySQL database as backend and Apache as web server. 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.3.
You should also adjust some settings to match your environment, namely:
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:
./manage.py syncdb
./manage.py migrate
To upgrade default set of privileges definitions (optional), run:
./manage.py setupgroups
To upgrade default set of language definitions (optional), run:
./manage.py setuplang
On upgrade to version 0.6 you should run ./manage.py syncdb and ./manage.py setupgroups –move to setup access control as described in installation section.
On upgrade to version 0.7 you should run ./manage.py syncdb to setup new tables and ./manage.py rebuild_index to build index for fulltext search.
On upgrade to version 0.8 you should run ./manage.py syncdb to setup new tables, ./manage.py setupgroups to update privileges setup and ./manage.py rebuild_index to rebuild index for fulltext search.
On upgrade to version 0.9 file structure has changed. You need to move repos and whoosh-index to weblate folder. Also running ./manage.py syncdb, ./manage.py setupgroups and ./manage.py setuplang is recommended to get latest updates of privileges and language definitions.
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);
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:
./manage.py syncdb
./manage.py migrate trans 0001 --fake
./manage.py migrate accounts 0001 --fake
./manage.py migrate 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.
Since 1.3, settings.py is not shipped with Weblate, but only example settings as settings_example.py it is recommended to use it as new base for your setup.
Several internal modules and paths have been renamed and changed, please adjust your settings.py to match that (consult settings_example.py for correct values).
The migration of database structure to 1.5 might take quite long, it is recommended to put your site offline, while the migration is going on.
Note
If you have update in same directory, stale *.pyc files might be left around and cause various import errors. To recover from this, delete all of them in Weblate’s directory, for example by find . -name '*.pyc' - delete.
The migration of database structure to 1.7 might take quite long, it is recommended to put your site offline, while the migration is going on.
If you are translating monolingual files, it is recommended to rerun quality checks as they might have been wrongly linked to units in previous versions.
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. Alternatively you can use importusers to import dumped user credentials.