Add Hebrew translations and automated preview deployment workflows

.github/workflows/FORK_PREVIEW_SETUP.md

@@ -0,0 +1,118 @@
+# Fork Preview Setup Guide
+
+This workflow automatically builds and deploys preview versions of the site when you push to branches in your fork. This allows you to review your changes before creating a PR to the main project.
+
+## How it works
+
+1. Fork the `github/training-kit` repository
+2. Push changes to any branch (except `main` or `gh-pages`)
+3. The workflow automatically builds the Jekyll site and deploys to your fork's GitHub Pages
+4. Preview is available at: `https://your-username.github.io/training-kit/preview/branch-name/`
+5. Review your changes before creating a PR to the main project
+
+## Setup Required (One-time setup)
+
+### 1. Enable GitHub Pages in your fork
+
+After you push your first branch, the workflow will create a `gh-pages` branch. Then:
+
+- Go to your fork's **Settings** → **Pages**
+- Under "Source", select **Deploy from a branch**
+- Select **gh-pages** branch and **/ (root)** folder
+- Click **Save**
+- GitHub Pages will be available at: `https://your-username.github.io/training-kit/`
+
+**That's it!** The workflow uses `GITHUB_TOKEN` which is automatically available in GitHub Actions - no PAT needed.
+
+## Preview URL Format
+
+Previews are organized by branch name:
+```
+https://{your-username}.github.io/training-kit/preview/{branch-name}/
+```
+
+For example:
+- Branch `add-spanish-translation` → `https://johndoe.github.io/training-kit/preview/add-spanish-translation/`
+- Branch `fix/typo` → `https://johndoe.github.io/training-kit/preview/fix-typo/` (slashes replaced with dashes)
+
+## Workflow
+
+### For Contributors (Translation/Content Editors)
+
+1. **Fork** the repository
+2. **Enable GitHub Pages** (one-time setup, see above)
+3. **Create a branch** with your changes
+4. **Push** to your fork
+5. **Check Actions tab** for the deployment status
+6. **Review** your preview at the URL shown in the workflow output
+7. **Create PR** to the main project once you're satisfied
+
+### Checking the Preview URL
+
+After pushing, you can find the preview URL in two places:
+
+1. **GitHub Actions output:**
+   - Go to your fork's **Actions** tab
+   - Click on the latest workflow run
+   - Expand the "Display preview URL" step
+   - Copy the preview URL
+
+2. **Direct URL pattern:**
+   - Just use: `https://your-username.github.io/training-kit/preview/your-branch-name/`
+
+## Benefits
+
+- ✅ **No approval required** - Runs automatically in your fork
+- ✅ **No PAT needed** - Uses built-in `GITHUB_TOKEN`
+- ✅ **Preview before PR** - Review changes before submitting to main project
+- ✅ **Multiple previews** - Each branch gets its own preview URL
+- ✅ **Easy for translators** - Non-technical contributors can see their work live
+
+## Managing Previews
+
+### Updating a Preview
+Just push new commits to the same branch - the preview updates automatically.
+
+### Cleaning Up Old Previews
+To remove old preview directories:
+1. Go to your fork
+2. Switch to the `gh-pages` branch
+3. Delete the `preview/branch-name/` directory
+4. Commit and push
+
+Or use git:
+```bash
+git checkout gh-pages
+git rm -rf preview/old-branch-name
+git commit -m "Remove old preview"
+git push
+```
+
+## Differences from Main Project
+
+- **Main project workflow:** Only deploys to production on push to `main`
+- **Fork preview workflow:** Deploys every branch to a preview URL in your fork
+
+## Security
+
+- Runs only in forks (not in the main `github/training-kit` repository)
+- Uses `GITHUB_TOKEN` with limited permissions
+- No secrets or PAT required
+- Each contributor controls their own fork and previews
+
+## Troubleshooting
+
+### Preview not showing up?
+1. Check if GitHub Pages is enabled in Settings → Pages
+2. Wait a few minutes - first deployment can take 5-10 minutes
+3. Check the Actions tab for any errors
+
+### 404 on preview URL?
+1. Make sure the branch name in the URL matches (slashes become dashes)
+2. Check if the workflow completed successfully
+3. Verify GitHub Pages is set to deploy from `gh-pages` branch
+
+### Workflow not running?
+1. Make sure you pushed to a branch (not `main` or `gh-pages`)
+2. Check that you're working in a fork, not the main repository
+3. Check the Actions tab is enabled in your fork settings

.github/workflows/PR_PREVIEW_SETUP.md

@@ -0,0 +1,73 @@
+# PR Preview Setup Guide
+
+This workflow automatically builds and deploys preview versions of the site for pull requests coming from forks. This is especially useful for translation reviews and content editing.
+
+## How it works
+
+1. When a PR is opened from a fork, the workflow builds the Jekyll site
+2. The built site is deployed to the fork's GitHub Pages under `pr-{number}/`
+3. A comment is posted on the PR with the preview URL
+4. The preview updates automatically when new commits are pushed
+
+## Setup Required (For Fork Owners)
+
+To enable preview deployments from your fork, you need to:
+
+### 1. Create a Fine-Grained Personal Access Token
+- Go to GitHub Settings → Developer settings → Personal access tokens → **Fine-grained tokens**
+- Click "Generate new token"
+- Configure the token:
+  - **Token name:** `PR Preview Deploy`
+  - **Expiration:** Choose your preferred expiration (90 days, 1 year, custom, or no expiration)
+  - **Resource owner:** Select yourself (the fork owner)
+  - **Repository access:** Select "Only select repositories"
+    - Choose your fork repository (e.g., `your-username/training-kit`)
+  - **Permissions → Repository permissions:**
+    - ✅ **Contents:** Read and write (required to push to gh-pages branch)
+    - ✅ **Pages:** Read and write (required to manage GitHub Pages)
+    - ✅ **Metadata:** Read-only (automatically included)
+- Click "Generate token"
+- **Copy the token immediately** (you won't see it again)
+
+### 2. Add the token to your fork's secrets
+- Go to your fork's Settings → Secrets and variables → Actions
+- Click "New repository secret"
+- Name: `PREVIEW_DEPLOY_TOKEN`
+- Value: Paste the fine-grained personal access token you created
+- Click "Add secret"
+
+### 3. Enable GitHub Pages in your fork (after first deployment)
+After the first PR preview is deployed, the gh-pages branch will be created automatically. Then:
+- Go to your fork's Settings → Pages
+- Under "Source", select "Deploy from a branch"
+- Select **gh-pages** branch and **/ (root)** folder
+- Click Save
+- GitHub Pages will be available at: `https://your-username.github.io/training-kit/`
+
+## Preview URL Format
+
+Previews will be available at:
+```
+https://{fork-owner}.github.io/{repo-name}/pr-{number}/
+```
+
+For example:
+```
+https://johndoe.github.io/training-kit/pr-42/
+```
+
+## Security
+
+- Only runs for PRs from forks (not internal PRs)
+- Uses `pull_request_target` to run in the context of the base repository
+- Checks out the specific PR SHA to build exactly what was submitted
+- Uses fine-grained PAT with minimal required permissions (Contents and Pages only)
+- Each fork owner controls their own credentials and deployment
+
+## Notes
+
+- The gh-pages branch is created automatically on first deployment
+- The first deployment may take a few minutes for GitHub Pages to become available
+- Previews persist until manually deleted from the gh-pages branch
+- Each PR gets its own isolated preview directory
+- You can clean up old previews by deleting directories from the gh-pages branch

.github/workflows/README.md

@@ -0,0 +1,136 @@
+# Preview Deployment Workflows
+
+This repository has two complementary preview workflows for a gradual review process:
+
+## 1. Fork Preview (Automated - No Approval Needed)
+**File:** `fork-preview.yml`
+
+Runs automatically in contributor forks when pushing to branches.
+
+### Purpose
+- Contributors can preview their changes before creating a PR
+- Translation teams can review content without waiting for maintainer approval
+- No setup required beyond enabling GitHub Pages
+
+### When it runs
+- On push to any branch in a fork (except `main` and `gh-pages`)
+- Automatically, no approval needed
+
+### Preview URL
+```
+https://{fork-owner}.github.io/training-kit/preview/{branch-name}/
+```
+
+### Setup
+See [FORK_PREVIEW_SETUP.md](./FORK_PREVIEW_SETUP.md)
+
+---
+
+## 2. PR Preview (Maintainer Approved)
+**File:** `pr-preview.yml`
+
+Runs when a PR is created from a fork to the main project.
+
+### Purpose
+- Maintainers can review the exact PR changes before merging
+- Provides a canonical preview URL for discussion in the PR
+- Allows fine-grained review with maintainer oversight
+
+### When it runs
+- On pull request events (opened, synchronize, reopened)
+- Requires maintainer approval for first-time contributors
+- Only for PRs from forks (not internal PRs)
+
+### Preview URL
+```
+https://{fork-owner}.github.io/training-kit/pr-{number}/
+```
+
+### Setup
+See [PR_PREVIEW_SETUP.md](./PR_PREVIEW_SETUP.md)
+
+---
+
+## Gradual Review Process
+
+### Step 1: Development & Self-Review (Fork Preview)
+1. **Contributor:** Fork the repository
+2. **Contributor:** Create a branch and push changes
+3. **Contributor:** Review at `https://{fork-owner}.github.io/training-kit/preview/{branch}/`
+4. **Contributor:** Iterate on changes, preview updates automatically
+
+### Step 2: Initial Discussion (Fork Preview)
+1. **Contributor:** Share fork preview URL with translation team/reviewers
+2. **Team:** Discuss and suggest changes using the fork preview
+3. **Contributor:** Make adjustments based on feedback
+4. **Team:** Approve when ready for formal PR
+
+### Step 3: PR Submission & Maintainer Review (PR Preview)
+1. **Contributor:** Create PR to main project
+2. **Maintainer:** Approve workflow run (first-time contributors only)
+3. **Workflow:** Deploys to `https://{fork-owner}.github.io/training-kit/pr-{number}/`
+4. **Maintainer & Team:** Final review using PR preview URL
+5. **Maintainer:** Approve and merge when ready
+
+---
+
+## Comparison
+
+| Feature | Fork Preview | PR Preview |
+|---------|-------------|------------|
+| **Trigger** | Push to fork branch | PR from fork |
+| **Approval needed** | No | Yes (first-time) |
+| **URL pattern** | `/preview/{branch}/` | `/pr-{number}/` |
+| **Best for** | Self-review, team discussion | Maintainer review |
+| **Setup** | Enable Pages only | Enable Pages + PAT |
+| **When to use** | During development | After PR created |
+
+---
+
+## Benefits of This Two-Stage Approach
+
+### For Contributors
+- ✅ Instant feedback without waiting for approval
+- ✅ Iterate quickly on changes
+- ✅ Share previews with translation teams
+- ✅ Submit PR only when ready
+
+### For Maintainers
+- ✅ Review already-vetted content
+- ✅ Control workflow execution for security
+- ✅ Canonical PR preview URL for discussion
+- ✅ Less time spent on back-and-forth
+
+### For Translation Teams
+- ✅ Review translations in context before PR
+- ✅ No technical knowledge needed
+- ✅ Faster approval process
+- ✅ Better quality submissions
+
+---
+
+## Which Setup Do I Need?
+
+### I'm a contributor/translator
+→ **Fork Preview only**
+- One-time: Enable GitHub Pages in your fork
+- See [FORK_PREVIEW_SETUP.md](./FORK_PREVIEW_SETUP.md)
+
+### I want PR previews too (optional)
+→ **Fork Preview + PR Preview**
+- Additionally: Create fine-grained PAT and add to secrets
+- See [PR_PREVIEW_SETUP.md](./PR_PREVIEW_SETUP.md)
+
+### I'm a maintainer
+→ **No setup needed**
+- Approve workflow runs as needed
+- Review using PR preview URLs
+
+---
+
+## Notes
+
+- Both workflows can coexist - use what fits your workflow
+- Fork previews work immediately with just GitHub Pages enabled
+- PR previews require additional PAT setup but provide PR-specific URLs
+- Contributors can use one or both depending on their needs