Módulos opcionales de Weblate#

Hay varios módulos opcionales disponibles para que los configure.

Git exporter#

Provides you read-only access to the underlying Git repository using HTTP(S).

Instalación#

  1. Add weblate.gitexport to installed apps in settings.py:

INSTALLED_APPS += ("weblate.gitexport",)
  1. Export existing repositories by migrating your database after installation:

weblate migrate

Uso#

The module automatically hooks into Weblate and sets the exported repository URL in the Configuración de componentes. The repositories are accessible under the /git/ part of the Weblate URL, for example https://example.org/git/weblate/main/.

Repositories for publicly available projects can be cloned without authentication:

git clone 'https://example.org/git/weblate/main/'

Access to browse the repositories with restricted access (with Private access control or when REQUIRE_LOGIN is enabled) requires an API token which can be obtained in your user profile:

git clone 'https://user:KEY@example.org/git/weblate/main/'

Consejo

By default members or Users group and anonymous user have access to the repositories for public projects via Access repository and Power user roles.

Facturación#

This is used on Hosted Weblate to define billing plans, track invoices and usage limits.

Instalación#

1. Add weblate.billing to installed apps in settings.py:

INSTALLED_APPS += ("weblate.billing",)
  1. Run the database migration to optionally install additional database structures for the module:

weblate migrate

Uso#

After installation you can control billing in the admin interface. Users with billing enabled will get new Billing tab in their Perfil de usuario.

The billing module additionally allows project admins to create new projects and components without being superusers (see Añadir proyectos y componentes de traducción). This is possible when following conditions are met:

  • The billing is in its configured limits (any overusage results in blocking of project/component creation) and paid (if its price is non zero)

  • The user is admin of existing project with billing or user is owner of billing (the latter is necessary when creating new billing for users to be able to import new projects).

Upon project creation user is able to choose which billing should be charged for the project in case he has access to more of them.

Avatars#

Avatars are downloaded and cached server-side to reduce information leaks to the sites serving them by default. The built-in support for fetching avatars from e-mails addresses configured for it can be turned off using ENABLE_AVATARS.

Weblate currently supports:

Spam protection#

You can protect against spamming by users by using the Akismet service.

  1. Install the akismet Python module (this is already included in the official Docker image).

  2. Obtain the Akismet API key.

  3. Store it as AKISMET_API_KEY or WEBLATE_AKISMET_API_KEY in Docker.

Following content is sent to Akismet for checking:

  • Sugerencias de usuarios no autenticados

  • Descripciones y enlaces de proyectos y componentes

Nota

This (among other things) relies on IP address of the client, please see Running behind reverse proxy for properly configuring that.

Signing Git commits with GnuPG#

All commits can be signed by the GnuPG key of the Weblate instance.

1. Turn on WEBLATE_GPG_IDENTITY. (Weblate will generate a GnuPG key when needed and will use it to sign all translation commits.)

This feature needs GnuPG 2.1 or newer installed.

You can find the key in the DATA_DIR and the public key is shown on the «About» page:

../_images/about-gpg.webp

2. Alternatively you can also import existing keys into Weblate, just set HOME=$DATA_DIR/home when invoking gpg.

Consejo

The key material is cached by Weblate for a long period. In case you let Weblate generate a key with WEBLATE_GPG_IDENTITY and then import key with the same identity to use an existing key, purging redis cache is recommended to see the effect of such change.

Nota

When sharing DATA_DIR between multiple hosts, please follow instructions at https://wiki.gnupg.org/NFS to make GnuPG signing work reliably.

Ver también

WEBLATE_GPG_IDENTITY

Rate limiting#

Distinto en la versión 4.6: The rate limiting no longer applies to superusers.

Several operations in Weblate are rate limited. At most RATELIMIT_ATTEMPTS attempts are allowed within RATELIMIT_WINDOW seconds. The user is then blocked for RATELIMIT_LOCKOUT. There are also settings specific to scopes, for example RATELIMIT_CONTACT_ATTEMPTS or RATELIMIT_TRANSLATE_ATTEMPTS. The table below is a full list of available scopes.

The following operations are subject to rate limiting:

Nombre

Alcance

Intentos permitidos

Oportunidad del límite de velocidad

Período de bloqueo

Registro

REGISTRATION

5

300

600

Enviar un mensaje a los administradores

MESSAGE

2

300

600

Autenticación de la contraseña al iniciar la sesión

LOGIN

5

300

600

Búsqueda en todo el sitio

SEARCH

6

60

60

Traducción

TRANSLATE

30

60

600

Adición al glosario

GLOSSARY

30

60

600

Comenzar una traducción en un idioma nuevo

LANGUAGE

2

300

600

Crear un nuevo proyecto

PROJECT

5

600

600

If a user fails to sign in AUTH_LOCK_ATTEMPTS times, password authentication will be turned off on the account until having gone through the process of having its password reset.

The settings can be also applied in the Docker container by adding WEBLATE_ prefix to the setting name, for example RATELIMIT_ATTEMPTS becomes WEBLATE_RATELIMIT_ATTEMPTS.

The API has separate rate limiting settings, see Limitación de la tasa de API.

Integración con Fedora Messaging#

Fedora Messaging es un publicador basado en AMQP para todos los cambios que ocurren en Weblate. Puede integrar servicios adicionales para actuar ante cambios que ocurran en Weblate mediante esta herramienta.

La integración con Fedora Messaging está disponible como un módulo Python separado, weblate-fedora-messaging. Consulte <https://github.com/WeblateOrg/fedora_messaging/> para obtener instrucciones de instalación.