Weblate basics#

Project and component structure#

In Weblate translations are organized into projects and components. Each project can contain number of components and those contain translations into individual languages. The component corresponds to one translatable file (for example GNU gettext or Android string resources). The projects are there to help you organize component into logical sets (for example to group all translations used within one application).

Internally, each project has translations to common strings propagated across other components within it by default. This lightens the burden of repetitive and multi version translation. The translation propagation can be disabled per Component configuration using Allow translation propagation in case the translations should diverge.

Repository integration#

Weblate is built to integrate with upstream version control repository, Continuous localization describes building blocks and how the changes flow between them.

See also

Architecture overview describes how Weblate works internally.

User attribution#

Weblate keeps the translations properly authored by translators in the version control repository by using name and e-mail. Having a real e-mail attached to the commit follows the distributed version control spirits and allows services like GitHub to associate your contributions done in Weblate with your GitHub profile.

This feature also brings in risk of misusing e-mail published in the version control commits. Moreover, once such a commit is published on public hosting (such as GitHub), there is effectively no way to redact it. Weblate allows choosing a private commit e-mail in Account to avoid this.

Therefore, admins should consider this while configuring Weblate:

  • Such a usage of e-mail should be clearly described in service terms in case such document is needed. Legal can help with that.

  • PRIVATE_COMMIT_EMAIL_OPT_IN can make e-mails private by default.