Weblate deployments¶
This is an overview of the supported deployment technologies.
Running Weblate with Docker¶
With dockerized Weblate deployment you can get your personal Weblate instance up an running in seconds. All of Weblate’s dependencies are already included. PostgreSQL is set up as the default database.
Deployment¶
The following examples assume you have a working Docker environment, with
docker-compose
installed. Please check the Docker documentation for instructions.
Clone the weblate-docker repo:
git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker cd weblate-docker
Create a
docker-compose.override.yml
file with your settings. See Docker environment variables for full list of environment variables.version: '3' services: weblate: environment: - WEBLATE_EMAIL_HOST=smtp.example.com - WEBLATE_EMAIL_HOST_USER=user - WEBLATE_EMAIL_HOST_PASSWORD=pass - WEBLATE_SERVER_EMAIL=weblate@example.com - WEBLATE_DEFAULT_FROM_EMAIL=weblate@example.com - WEBLATE_ALLOWED_HOSTS=weblate.example.com,localhost - WEBLATE_ADMIN_PASSWORD=password for the admin user - WEBLATE_ADMIN_EMAIL=weblate.admin@example.com
Nota
If
WEBLATE_ADMIN_PASSWORD
is not set, the admin user is created with a random password shown on first startup.Append “,localhost” to WEBLATE_ALLOWED_HOSTS to be able to access locally for testing.
You may also need to edit the docker-compose.yml file and change the default port from 80 if you already have a web server running on your local machine
Start Weblate containers:
docker-compose up
Enjoy your Weblate deployment, it’s accessible on port 80 of the weblate
container.
Distinto en la versión 2.15-2: The setup has changed recently, priorly there was separate web server container, since 2.15-2 the web server is embedded in the Weblate container.
Ver también
Docker container with HTTPS support¶
Please see Deployment for generic deployment instructions. To add a
reverse HTTPS proxy an additional Docker container is required,
https-portal will be used.
This is made use of in the docker-compose-https.yml
file.
Then create a docker-compose-https.override.yml
file with your settings:
version: '3'
services:
weblate:
environment:
- WEBLATE_EMAIL_HOST=smtp.example.com
- WEBLATE_EMAIL_HOST_USER=user
- WEBLATE_EMAIL_HOST_PASSWORD=pass
- WEBLATE_ALLOWED_HOSTS=weblate.example.com
- WEBLATE_ADMIN_PASSWORD=password for admin user
https-portal:
environment:
DOMAINS: 'weblate.example.com -> http://weblate'
Whenever invoking docker-compose you need to pass both files to it, and then do:
docker-compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker-compose -f docker-compose-https.yml -f docker-compose-https.override.yml up
Upgrading the Docker container¶
Usually it is good idea to only update the Weblate container and keep the PostgreSQL container at the version you have, as upgrading PostgreSQL is quite painful and in most cases does not bring many benefits.
You can do this by sticking with the existing docker-compose and just pull the latest images and then restart:
docker-compose stop
docker-compose pull
docker-compose up
The Weblate database should be automatically migrated on first startup, and there should be no need for additional manual actions.
Nota
Upgrades across 3.0 are not supported by Weblate. If you are on 2.x series
and want to upgrade to 3.x, first upgrade to the latest 3.0.1-x (at time of
writing this it is the 3.0.1-7
) image, which will do the migration and then
continue upgrading to newer versions.
Docker environment variables¶
Many of Weblate’s Configuration can be set in the Docker container using environment variables:
Generic settings¶
-
WEBLATE_DEBUG
¶ Configures Django debug mode using
DEBUG
.Example:
environment: - WEBLATE_DEBUG=1
Ver también
-
WEBLATE_LOGLEVEL
¶ Configures the logging verbosity.
-
WEBLATE_SITE_TITLE
¶ Configures the site-title shown on the heading of all pages.
-
WEBLATE_ADMIN_NAME
¶
-
WEBLATE_ADMIN_EMAIL
¶ Configures the site-admin’s name and email.
Example:
environment: - WEBLATE_ADMIN_NAME=Weblate admin - WEBLATE_ADMIN_EMAIL=noreply@example.com
Ver también
-
WEBLATE_ADMIN_PASSWORD
¶ Sets the password for the admin user. If not set, the admin user is created with a random password shown on first startup.
Distinto en la versión 2.9: Since version 2.9, the admin user is adjusted on every container startup to match
WEBLATE_ADMIN_PASSWORD
,WEBLATE_ADMIN_NAME
andWEBLATE_ADMIN_EMAIL
.
-
WEBLATE_SERVER_EMAIL
¶
-
WEBLATE_DEFAULT_FROM_EMAIL
¶ Configures the address for outgoing emails.
Ver también
-
WEBLATE_ALLOWED_HOSTS
¶ Configures allowed HTTP hostnames using
ALLOWED_HOSTS
and sets sitename to the first one.Example:
environment: - WEBLATE_ALLOWED_HOSTS=weblate.example.com,example.com
Ver también
-
WEBLATE_SECRET_KEY
¶ Configures the secret used by Django for cookie signing.
Obsoleto desde la versión 2.9: The secret is now generated automatically on first startup, there is no need to set it manually.
Ver también
-
WEBLATE_REGISTRATION_OPEN
¶ Configures whether registrations are open by toggling
REGISTRATION_OPEN
.Example:
environment: - WEBLATE_REGISTRATION_OPEN=0
-
WEBLATE_TIME_ZONE
¶ Configures the used time-zone.
-
WEBLATE_ENABLE_HTTPS
¶ Makes Weblate assume it is operated behind a reverse HTTPS proxy, it makes Weblate use HTTPS in email and API links or set secure flags on cookies.
Nota
This does not make the Weblate container accept HTTPS connections, you need to use a standalone reverse HTTPS proxy, see Docker container with HTTPS support for example.
Example:
environment: - WEBLATE_ENABLE_HTTPS=1
Ver también
-
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 setsIP_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
-
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
toWEBLATE_ADMIN_EMAIL
.
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
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
-
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
-
WEBLATE_EMAIL_HOST
¶ Mail server, the server has to listen on port 587 and understand TLS.
Ver también
-
WEBLATE_EMAIL_PORT
¶ Mail server port. Use if your cloud provider or ISP blocks outgoing connections on port 587.
Ver también
-
WEBLATE_EMAIL_HOST_USER
¶ Email authentication user, do NOT use quotes here.
Ver también
-
WEBLATE_EMAIL_HOST_PASSWORD
¶ Email authentication password, do NOT use quotes here.
Ver también
-
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
-
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
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
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
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
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