Addons¶

New in version 2.19.

Addons provide ways to customize translation workflow. They can be installed in the translation component view, and work behind the scenes. Addon management is available from the Manage ↓ Addons menu of each respective translation component for admins.

Built-in addons¶

Automatic translation¶

New in version 3.9.

Automatically translates strings using machine translation or other components.

This addon is triggered automatically when new strings appear in a component.

JavaScript localization CDN¶

New in version 4.2.

Adds localization CDN for JavaScript or HTML localization.

It can be used to localize static HTML pages or used to load localization in the JavaScript code.

Upon installation the addon generates unique URL for your component which you can include in the HTML documents to get them localized. See Translating HTML and JavaScript using Weblate CDN for more details.

Remove blank strings¶

New in version 4.4.

Removes strings without a translation from translation files.

Use this if you do not want empty strings to appear in translation files (for example when your localization library displays them as empty strings instead of falling back to the source string).

Cleanup translation files¶

Update all translation files to match the monolingual base file. For most file formats, this means removing stale translation keys no longer present in the base file.

Language consistency¶

Ensures all components within one project have translations for every added language for translation.

It creates empty translations in languages that have unadded components.

Missing languages are checked once every 24 hours and when a new language is added in Weblate.

Unlike most others, this addon affects the whole project.

Hint

Auto-translate the newly added strings with Automatic translation.

Component discovery¶

Automatically adds or removes project components based on file changes in the version control system.

It is triggered on every VCS update, and otherwise similar to the import_project management command. This way you can track multiple translation components within one VCS.

Create one main component least likely to disappear in the future, and others will employ Weblate internal URLs to it as a VCS configuration, and configure it to find all components in it.

The matching is done using regular expressions, where power is a tradeoff for complexity in configuration. Some examples for common use cases can be found in the addon help section.

Once you hit Save, a preview of matching components will be presented, from where you can check whether the configuration actually matches your needs:

See also

Template markup

Bulk edit¶

New in version 3.11.

Bulk edit flags, labels or state for strings.

Automating the labeling of new strings can be useful (start out with search query NOT has:label and add desired labels till all strings are properly labeled). You can also carry out any other automated operations for Weblate metadata.

Examples:

Automatically add label to new strings¶
Search query	`NOT has:label`
Labels to add	recent

Marking all App store metadata files changelog entries read-only¶
Search query	`language:en AND key:changelogs/`
Translation flags to add	`read-only`

See also

Bulk edit

Flag unchanged translations as «Needs editing»¶

New in version 3.1.

Whenever a new translatable string is imported from the VCS and it matches a source string, it is flagged as needing editing in Weblate. This is especially useful for file formats that include all strings even if not translated.

Flag new source strings as «Needs editing»¶

Whenever a new source string is imported from the VCS, it is flagged as needing editing in Weblate. This way you can easily filter and edit source strings written by the developers.

Flag new translations as «Needs editing»¶

Whenever a new translatable string is imported from the VCS, it is flagged as needing editing in Weblate. This way you can easily filter and edit translations created by the developers.

Statistics generator¶

Generates a file containing detailed info about the translation status.

You can use Django template in both filename and content, see Template markup for a detailed markup description.

For example generating summary file for each translation:

Name of generated file

locale/{{ language_code }}.json

Content

{
   "language": "{{ language_code }}",
   "strings": "{{ stats.all }}",
   "translated": "{{ stats.translated }}",
   "last_changed": "{{ stats.last_changed }}",
   "last_author": "{{ stats.last_author }}",
}

See also

Template markup

Contributors in comment¶

Update the comment in the PO file header to include contributor names and years of contributions.

The PO file header will contain a list of contributors and years contributed:

# Michal Čihař <michal@cihar.com>, 2012, 2018, 2019, 2020.
# Pavel Borecki <pavel@example.com>, 2018, 2019.
# Filip Hron <filip@example.com>, 2018, 2019.
# anonymous <noreply@weblate.org>, 2019.

Update ALL_LINGUAS variable in the «configure» file¶

Updates the ALL_LINGUAS variable in configure, configure.in or any configure.ac files, when a new translation is added.

Customize gettext output¶

Allows customization of gettext output behavior, for example line wrapping.

It offers the following options:

Wrap lines at 77 characters and at newlines
Only wrap lines at newlines
No line wrapping

Note

By default gettext wraps lines at 77 characters and for newlines. With the --no-wrap parameter, it wraps only at newlines.

Update LINGUAS file¶

Updates the LINGUAS file when a new translation is added.

Generate MO files¶

Automatically generates a MO file for every changed PO file.

The location of the generated MO file can be customized and the field for it uses Template markup.

Update PO files to match POT (msgmerge)¶

Updates all PO files (as configured by File mask) to match the POT file (as configured by Template for new translations) using msgmerge.

This addon is triggered whenever new changes are pulled from the upstream repository. You can configure most of the msgmerge command line options through the addon configuration.

Squash Git commits¶

Squash Git commits prior to pushing changes.

You can choose one of following modes:

New in version 3.4.

All commits into one
Per language
Per file

New in version 3.5.

Per author

Original commit messages are kept, but authorship is lost unless Per author is selected, or the commit message is customized to include it.

New in version 4.1.

The original commit messages can optionally be overridden with a custom commit message.

Trailers (commit lines like Co-authored-by: ...) can optionally be removed from the original commit messages and appended to the end of the squashed commit message. This also generates proper Co-authored-by: credit for every translator.

Customize JSON output¶

Allows adjusting JSON output behavior, for example indentation or sorting.

Formats the Java properties file¶

Sorts the Java properties file.

Stale comment removal¶

New in version 3.7.

Set a timeframe for removal of comments.

This can be useful to remove old comments which might have become outdated. Use with care as comment being old does not mean they have lost their importance.

Stale suggestion removal¶

New in version 3.7.

Set a timeframe for removal of suggestions.

This can be very useful in connection with suggestion voting (see Peer review) to remove suggestions which don’t receive enough positive votes in a given timeframe.

Update RESX files¶

New in version 3.9.

Update all translation files to match the monolingual upstream base file. Unused strings are removed, and new ones added as copies of the source string.

Hint

Use Cleanup translation files if you only want to remove stale translation keys.

Customize YAML output¶

New in version 3.10.2.

Allows adjusting YAML output behavior, for example line-length or newlines.

Customizing list of addons¶

The list of addons is configured by WEBLATE_ADDONS. To add another addon, simply include class absolute name in this setting.

Writing addon¶

You can write your own addons too, all you need to do is subclass weblate.addons.base.BaseAddon, define the addon metadata and implement a callback which will do the processing.

See also

Developing addons

Executing scripts from addon¶

Addons can also be used to execute external scripts. This used to be integrated in Weblate, but now you have to write some code to wrap your script with an addon.

#
# Copyright © 2012 - 2020 Michal Čihař <michal@cihar.com>
#
# This file is part of Weblate <https://weblate.org/>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#
"""Example pre commit script."""


from django.utils.translation import gettext_lazy as _

from weblate.addons.events import EVENT_PRE_COMMIT
from weblate.addons.scripts import BaseScriptAddon


class ExamplePreAddon(BaseScriptAddon):
    # Event used to trigger the script
    events = (EVENT_PRE_COMMIT,)
    # Name of the addon, has to be unique
    name = "weblate.example.pre"
    # Verbose name and long descrption
    verbose = _("Execute script before commit")
    description = _("This addon executes a script.")

    # Script to execute
    script = "/bin/true"
    # File to add in commit (for pre commit event)
    # does not have to be set
    add_file = "po/{{ language_code }}.po"

For installation instructions see Custom quality checks, addons and auto-fixes.

The script is executed with the current directory set to the root of the VCS repository for any given component.

Additionally, the following environment variables are available:

WL_VCS¶: Version control system used.

WL_REPO¶: Upstream repository URL.

WL_PATH¶: Absolute path to VCS repository.

WL_BRANCH¶: New in version 2.11.

Repository branch configured in the current component.

WL_FILEMASK¶: Filemask for current component.

WL_TEMPLATE¶: Filename of template for monolingual translations (can be empty).

WL_NEW_BASE¶: New in version 2.14.

Filename of the file used for creating new translations (can be empty).

WL_FILE_FORMAT¶: Fileformat used in current component.

WL_LANGUAGE¶: Language of currently processed translation (not available for component level hooks).

WL_PREVIOUS_HEAD¶: Previous HEAD on update (available only when running post update hook).

WL_COMPONENT_SLUG¶: New in version 3.9.

Component slug used to construct URL.

WL_PROJECT_SLUG¶: New in version 3.9.

Project slug used to construct URL.

WL_COMPONENT_NAME¶: New in version 3.9.

Component name.

WL_PROJECT_NAME¶: New in version 3.9.

Project name.

WL_COMPONENT_URL¶: New in version 3.9.

Component URL.

WL_ENGAGE_URL¶: New in version 3.9.

Project engage URL.

See also

Component configuration

Post update repository processing¶

Post update repository processing can be used to update translation files when the VCS upstream source changes. To achieve this, please remember that Weblate only sees files committed to the VCS, so you need to commit changes as a part of the script.

For example with Gulp you can do it using following code:

#! /bin/sh
gulp --gulpfile gulp-i18n-extract.js
git commit -m 'Update source strings' src/languages/en.lang.json

Pre commit processing of translations¶

Use the commit script to automatically make changes to the translation before it is committed to the repository.

It is passed as a single parameter consisting of the filename of a current translation.