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-cairo python-gtk2 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-cairo python-South python-gtk
PyCairo and PyGtk are available to be installed using brew, all other requirements must be installed using pip as explained next. In a terminal:
brew update
brew install py2cairo pygtk
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
However you need to get PyCairo and PyGtk for your platform elsewhere as they do not support this easy installation method. Check their website for options for getting appropriate binaries.
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
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 backtrackes 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.
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.
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.
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.2.
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.
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.