QGIS-Website: The Hugo Source Repository for QGIS.org

What QGIS-Website Contains and What It Does Not Cover

QGIS-Website hosts the source code for qgis.org, the primary public-facing home of the QGIS open-source geographic information system project. The repository builds the project home page, news articles, visual changelogs, the sustaining members listing, and a Flickr gallery. It does not contain the QGIS desktop application, the plugins registry, the resource hub, or any of the eight subdomain sites the QGIS project maintains.

Each subdomain runs from its own repository. QGIS-Plugins-Website powers plugins.qgis.org. QGIS-Hub-Website serves hub.qgis.org. The qgis-feed repository runs feed.qgis.org. QGIS-Planet-Website manages planet.qgis.org. QGIS-Members-Website handles members.qgis.org. QGIS-Certification-Website runs certification.qgis.org. QGIS-Changelog-Website manages changelog.qgis.org. QGIS-UC-Website serves conference.qgis.org. A contributor who wants to change something at plugins.qgis.org must go to the QGIS-Plugins-Website repository, not this one.

The repository's primary language is listed as Python, which reflects the data scripts. The static site itself is generated by Hugo, a Go-based static site generator. The project is licensed under the MIT License, and the last push to the main branch was on 2026-09-28.

Repository Layout and Hugo Directory Conventions

The folder structure follows Hugo conventions. The content/ directory holds Markdown pages and posts in the default language. The layouts/ directory contains Hugo templates and partials. The data/ directory stores YAML, JSON, and TOML files consumed by templates at build time. The config/ directory holds Hugo configuration files, including config.prod.toml for qgis.org and config.www.toml for www.qgis.org.

The assets/ directory mainly stores the schedule.csv file used for conference and event listings. The translations/ and content-translated/ directories support the internationalization pipeline. The i18n/ directory holds string-level translation files. The .tx/ directory contains a Transifex client configuration, indicating that translation coordination runs through that platform. The playwright/ directory holds end-to-end test scripts, and .github/ stores the GitHub Actions workflow definitions for automated builds, link checking, and deployment.

The themes/ directory holds the Hugo theme. The static/ directory holds static assets served directly. The public/ directory is the generated site output and is excluded from version control.

Building QGIS.org Locally from the Makefile

The Makefile is the primary entry point for working with the repository. The build target generates the site for both qgis.org and www.qgis.org:

make build

This target calls scripts/get_commit_hash.sh to write the current commit hash into config/commit.toml, then invokes scripts/build_prod_per_lang.sh for each of the two production configurations. The output lands in public_prod for qgis.org and public_www for www.qgis.org. The deploy target pushes the built site live and is separate from the build step.

Code formatting is handled through Prettier with the prettier-plugin-go-template plugin, declared in package.json. Before committing Hugo template changes, contributors should run the format check:

npm run format:check

The vscode.sh script launches Visual Studio Code with all required settings and extensions pre-configured. The DEVELOPMENT.md file covers incremental per-language builds, which reduce rebuild time when working on a single locale, and documents media deduplication behavior.

Python Scripts That Populate Live Content

Several Python scripts run outside the Hugo build to populate data files that the templates consume. The fetch_feeds.py script pulls sustaining member data from external feeds, updates content/funders/, writes news feed data to data/feed.json, and refreshes the Flickr gallery content at content/flickr-images/. It is the mechanism by which the website reflects current sponsorship information without requiring a manual update to the Hugo content files.

The changelog_harvest.py script creates and updates visual changelog pages at content/project/visual-changelogs, drawing from release data in data/conf.json. The get_commit_hash.sh script writes the current commit hash into config/commit.toml so the site footer can display a version identifier.

All these scripts are in the scripts/ directory alongside build_prod_per_lang.sh. The README does not document a scheduler or automated trigger for the data scripts, so the cadence at which they run in production is not visible from the repository alone. A contributor who wants to update sponsor data or refresh changelog pages must run the appropriate script manually before triggering a Hugo build.

Internationalization Authoring Rules and the Translation Pipeline

The I18N.md file defines the internationalization workflow. Three authoring constraints apply specifically to content that will pass through the translation tooling. Shortcode parameters must have spaces around the equals sign. The closing shortcode delimiter (>}}) must stay on the same line as the parameter block. Inline HTML is not permitted inside Markdown content files.

Violating any of these three constraints breaks the translation extraction pipeline rather than producing a visible error at Hugo build time. The failure shows up later in the translation tools, which makes the rules easy to overlook during initial content authoring.

Contributors must follow CONTRIBUTING.md alongside I18N.md. The content-translated/ directory stores translated content, separate from the canonical English content/ directory. DEVELOPMENT.md covers incremental per-language builds, which matter when a contributor is iterating on a single locale without wanting to rebuild every language.

LLM Use Policy and the Automated QA Pipeline

The README includes an explicit policy on using large language models as a contributor. Three conditions apply. First, any verbatim LLM output included in the repository must be accompanied by the prompt that generated it. Second, including the prompt serves as the implicit declaration of LLM use. If the machine-generated nature is not obvious from context, contributors must mark the affected snippet with a robot icon. Third, contributors take full responsibility for validating the output and ensuring its correctness, regardless of how it was generated.

This policy applies to code and text alike. A contributor using an LLM to draft a Hugo partial, a translation string, or a Python script must include the prompt in the pull request.

The automated QA pipeline consists of three GitHub Actions workflows: Playwright end-to-end tests, a GitHub Pages deployment check, and an internal link checker on the built site. Each is defined in .github/ and runs automatically against pull requests. The link checker catches broken internal references before they reach production.

Limitations, Alternatives, and Upgrade Considerations

Hugo version upgrades can break template syntax, particularly if the upgrade introduces changes to shortcode handling or deprecated template functions. The prettier-plugin-go-template version is pinned in package-lock.json, so running npm install restores it. Python script dependencies are not declared in a requirements file at the repository root, so updating fetch_feeds.py or changelog_harvest.py may require manual dependency reconciliation.

The repository is the source only for the main qgis.org site. A team wishing to contribute across multiple QGIS web properties must understand the subdomain split and work across at least two repositories.

The obvious comparison for this kind of website project is Jekyll with GitHub Pages, which has native GitHub Actions integration and a large theme ecosystem. Hugo generates static sites significantly faster on large content trees, which is why QGIS-Website uses per-language incremental builds. Teams without prior Hugo experience should budget time for the learning curve before contributing to the layouts/ or themes/ directories. Teams who need only content or data updates can work in content/ or by running the Python scripts, without touching templates at all.

Editorial conclusion

Engineers comfortable with Hugo, Python scripting, and GitHub Actions can contribute to QGIS-Website without touching the QGIS desktop application codebase at all. The right first step is to run make build locally and verify the Playwright tests pass before opening a pull request. Any contributor using an LLM tool must include the generating prompt in the submission. Subdomain work belongs in its own repository, so confirm which subdomain site you mean to change before cloning.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository