Installing from sources¶

Please follow the installation instructions for your system first up to installing Weblate:
Grab the latest Weblate sources using Git (or download a tarball and unpack that):
```
git clone https://github.com/WeblateOrg/weblate.git weblate-src
```
Alternatively you can use released archives. You can download them from our website <https://weblate.org/>. Those downloads are cryptographically signed, please see Verifying release signatures.
Install current Weblate code into the Python environment:
```
. ~/weblate-env/bin/activate
uv pip install -e 'weblate-src[all]'
```
If you intend to run the testsuite from the source checkout, install the development dependencies as described in Local testing of Weblate.
Copy weblate/settings_example.py to weblate/settings.py.
Adjust the values in the new settings.py file to your liking. You will need to provide at least the database credentials and Django secret key, but you will want more changes for production setup, see Adjusting configuration.
Create the database used by Weblate, see Database setup for Weblate.
Build Django tables, static files and initial data (see Filling up the database and Serving static files):
```
weblate migrate
weblate collectstatic
weblate compress
```
Note

This step should be repeated whenever you update the repository.

Packaging Weblate for distributions¶

The dependency versions in pyproject.toml describe the runtime environment tested by the Weblate project. They are intentionally strict for installs from PyPI and for the Weblate release process, because Weblate cannot validate every dependency-version combination covered by wider version ranges.

Distribution packages can replace those Python packages with versions from the distribution package set. When doing so, run Weblate’s test suite against the packaged dependency set and treat passing tests as the compatibility signal for the distribution package.

Keep Weblate’s tightly coupled companion packages in sync with the Weblate release:

Mismatched versions of these packages are more likely to break at runtime or during tests than other Python dependency substitutions.