Principle:OWASP Www project top 10 for large language model applications Translation Publication
| Knowledge Sources | OWASP/www-project-top-10-for-large-language-model-applications |
|---|---|
| Domains | Localization, Publication, CI/CD, Site Deployment |
| Last Updated | 2026-02-14 |
Overview
Translation publication integrates validated translations into the project through the GitHub pull request workflow, automated checks, and Jekyll site deployment.
Description
Once translations have been completed and validated, they must be integrated into the project repository and published to the project website at genai.owasp.org. Translation publication defines the end-to-end process for moving validated translation files from a contributor's working branch into the main branch, triggering automated checks, and rebuilding the static site.
The problem this solves is uncontrolled integration. Without a structured publication process, translations could be merged with broken filenames, missing files, inconsistent PR descriptions, or without proper review. The publication workflow enforces filename validation through CI checks, auto-generates informative PR descriptions using an AI-assisted tool, applies the project's PR template for structured change documentation, and ultimately triggers a Jekyll site rebuild that makes the translations available to the global audience.
The project currently maintains 10 active translation locales (de-DE, el-GR, es-ES, hi-IN, ja-JP, ko-KR, pt-BR, ru-RU, zh-CN, zh-TW), each published through this workflow to the genai.owasp.org static site.
Usage
Use translation publication when:
- A translator has completed and validated all files for a locale and is ready to submit
- Updating existing translations after English source entries have changed
- Adding a new locale to the project for the first time
- Reviewing incoming translation PRs as a project maintainer
- Troubleshooting failed CI checks on translation pull requests
Theoretical Basis
The publication methodology follows a multi-stage pipeline from contributor branch to live site.
Stage 1: Branch and PR Preparation
Contributors create a feature branch with their translation files, following the project's contribution guidelines (CONTRIBUTING.md). The contribution guide directs contributors to:
- Consult the style guide at
documentation/style/README.md - Join community sync meetings and Slack channels
- Submit translations, publishing contributions, and data gathering efforts
- No OWASP membership is required to contribute
Stage 2: Pull Request Creation
The PR is created using the project's PR template (.github/PULL_REQUEST_TEMPLATE.md), which structures the change description into:
- Key Changes -- Major changes and core updates
- Added -- New features, files, configurations, and dependencies
- Changed -- Updates to existing code, configuration changes
- Removed -- Deleted files, removed dependencies, cleaned configurations
Stage 3: Automated PR Description Generation
The project provides an optional AI-assisted PR description generator (.hooks/generate_pr_description.py) that uses the rigging library with GPT-4o-mini to analyze the git diff and produce a concise, developer-focused PR description. The tool:
- Computes the merge base between the source and target branches
- Generates a diff (limited to 1000 lines by default)
- Sends the diff to GPT-4o-mini with guidance for concise, bullet-pointed summaries
- Returns a markdown-formatted PR description
# Pseudocode for PR description generation
def generate_pr_description(base_ref, source_ref, generator_id):
diff = get_git_diff(base_ref, source_ref)
if len(diff.lines) > MAX_DIFF_LINES:
diff = truncate(diff, MAX_DIFF_LINES)
description = ai_generate(diff, model=generator_id)
return description
Stage 4: CI/CD Filename Validation
The GitHub Actions workflow .github/workflows/check-filenames-pr.yml automatically validates that all files in the PR follow the project's naming conventions. This ensures translation files maintain their expected naming pattern (e.g., LLM01_PromptInjection.md, Supplemental_Content.md, ADD00_Cover.md).
Stage 5: Review and Merge
Project maintainers review the PR for content quality, structural correctness, and completeness. Once approved, the PR is merged into the main branch.
Stage 6: Jekyll Site Rebuild
The project uses Jekyll with the OWASP site theme (_config.yml specifies remote_theme: "owasp/www--site-theme@main") and the jekyll-include-cache plugin. Upon merge to main, the Jekyll build process regenerates the static site at genai.owasp.org, making the new translations publicly available.
Key Invariants:
- All translation PRs must pass the filename validation CI check before merge
- The PR template ensures structured documentation of all changes
- The Jekyll site rebuilds automatically on merge to main
- The project maintains vendor neutrality as stated in the contribution guidelines
- No OWASP membership is required to contribute translations