lokalise-ci-integration
Configure Lokalise CI/CD integration with GitHub Actions and automated sync. Use when setting up automated translation sync, configuring CI pipelines, or integrating Lokalise into your build process. Trigger with phrases like "lokalise CI", "lokalise GitHub Actions", "lokalise automated sync", "CI lokalise", "lokalise pipeline".
What this skill does
# Lokalise CI Integration
## Overview
Automate the full translation lifecycle through GitHub Actions: upload source strings when code is pushed, download translations during builds, block PRs with missing translations, and manage branch-based translation workflows that mirror your Git branching strategy. The goal is zero manual translation file management — developers write code, translators work in Lokalise, and CI keeps everything in sync.
## Prerequisites
- Lokalise project with Project ID (Settings > General > Project ID)
- Lokalise API token with read/write permissions (Profile > API Tokens), stored as `LOKALISE_API_TOKEN` GitHub secret
- `LOKALISE_PROJECT_ID` stored as GitHub secret (or variable)
- Lokalise CLI v2 (`lokalise2`) — installed in CI via `curl -sfL https://raw.githubusercontent.com/nicktomlin/lokalise-cli-2-install/master/install.sh | sh`
- Source locale files committed to the repository (e.g., `src/locales/en.json`)
## Instructions
### Step 1: Upload Source Strings on Push
Create `.github/workflows/lokalise-upload.yml` to push source strings to Lokalise whenever the default locale file changes on `main`:
```yaml
name: Upload translations to Lokalise
on:
push:
branches: [main]
paths:
- 'src/locales/en.json' # Adjust to your source locale path
jobs:
upload:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Lokalise CLI
run: |
curl -sfL https://raw.githubusercontent.com/lokalise/lokalise-cli-2-go/master/install.sh | sh
sudo mv ./bin/lokalise2 /usr/local/bin/lokalise2
- name: Upload source strings
run: |
lokalise2 file upload \
--token "${{ secrets.LOKALISE_API_TOKEN }}" \
--project-id "${{ secrets.LOKALISE_PROJECT_ID }}" \
--file "src/locales/en.json" \
--lang-iso "en" \
--replace-modified \
--include-path \
--distinguish-by-file \
--poll \
--poll-timeout 120s
# --replace-modified updates existing keys with new values
# --poll waits for the async upload to complete before exiting
```
### Step 2: Download Translations During Build
Create `.github/workflows/lokalise-build.yml` or add a step to your existing build workflow:
```yaml
name: Build with translations
on:
push:
branches: [main, staging]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Lokalise CLI
run: |
curl -sfL https://raw.githubusercontent.com/lokalise/lokalise-cli-2-go/master/install.sh | sh
sudo mv ./bin/lokalise2 /usr/local/bin/lokalise2
- name: Download translations
run: |
lokalise2 file download \
--token "${{ secrets.LOKALISE_API_TOKEN }}" \
--project-id "${{ secrets.LOKALISE_PROJECT_ID }}" \
--format json \
--original-filenames=true \
--directory-prefix="" \
--export-empty-as=base \
--unzip-to "src/locales/"
# --export-empty-as=base falls back to source language for untranslated keys
# --original-filenames preserves the file structure from Lokalise
- name: Build application
run: npm run build
```
### Step 3: PR Check for Missing Translations
Add a workflow that comments on PRs when new translation keys lack translations in required locales:
```yaml
name: Translation coverage check
on:
pull_request:
paths:
- 'src/locales/**'
jobs:
check-translations:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check translation coverage
run: |
#!/bin/bash
set -euo pipefail
REQUIRED_LOCALES=("en" "de" "fr" "es" "ja")
SOURCE_FILE="src/locales/en.json"
MISSING=0
REPORT=""
source_keys=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$SOURCE_FILE" | sort)
for locale in "${REQUIRED_LOCALES[@]}"; do
locale_file="src/locales/${locale}.json"
if [[ ! -f "$locale_file" ]]; then
REPORT+="- **${locale}**: File missing entirely\n"
MISSING=1
continue
fi
locale_keys=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$locale_file" | sort)
missing_keys=$(comm -23 <(echo "$source_keys") <(echo "$locale_keys"))
if [[ -n "$missing_keys" ]]; then
count=$(echo "$missing_keys" | wc -l)
REPORT+="- **${locale}**: ${count} missing keys\n"
MISSING=1
fi
done
if [[ $MISSING -eq 1 ]]; then
echo "## Translation Coverage Report" >> "$GITHUB_STEP_SUMMARY"
echo "" >> "$GITHUB_STEP_SUMMARY"
echo -e "$REPORT" >> "$GITHUB_STEP_SUMMARY"
echo "" >> "$GITHUB_STEP_SUMMARY"
echo "Run \`lokalise2 file download\` to pull latest translations." >> "$GITHUB_STEP_SUMMARY"
exit 1
fi
echo "All locales have complete translation coverage." >> "$GITHUB_STEP_SUMMARY"
```
### Step 4: Integration Tests for Key Coverage
Add a test that validates translation files have all required keys at build time:
```typescript
// tests/i18n-coverage.test.ts
import { describe, it, expect } from 'vitest';
import fs from 'fs';
import path from 'path';
const LOCALES_DIR = path.resolve(__dirname, '../src/locales');
const SOURCE_LOCALE = 'en';
const REQUIRED_LOCALES = ['en', 'de', 'fr', 'es', 'ja'];
function flattenKeys(obj: Record<string, unknown>, prefix = ''): string[] {
return Object.entries(obj).flatMap(([key, value]) => {
const fullKey = prefix ? `${prefix}.${key}` : key;
if (typeof value === 'object' && value !== null && !Array.isArray(value)) {
return flattenKeys(value as Record<string, unknown>, fullKey);
}
return [fullKey];
});
}
describe('Translation coverage', () => {
const sourceFile = JSON.parse(
fs.readFileSync(path.join(LOCALES_DIR, `${SOURCE_LOCALE}.json`), 'utf-8')
);
const sourceKeys = flattenKeys(sourceFile).sort();
for (const locale of REQUIRED_LOCALES) {
it(`${locale}.json contains all source keys`, () => {
const localeFile = JSON.parse(
fs.readFileSync(path.join(LOCALES_DIR, `${locale}.json`), 'utf-8')
);
const localeKeys = flattenKeys(localeFile).sort();
const missing = sourceKeys.filter(k => !localeKeys.includes(k));
expect(missing, `Missing keys in ${locale}: ${missing.join(', ')}`).toHaveLength(0);
});
}
it('no orphaned keys exist in non-source locales', () => {
for (const locale of REQUIRED_LOCALES.filter(l => l !== SOURCE_LOCALE)) {
const localeFile = JSON.parse(
fs.readFileSync(path.join(LOCALES_DIR, `${locale}.json`), 'utf-8')
);
const localeKeys = flattenKeys(localeFile);
const orphaned = localeKeys.filter(k => !sourceKeys.includes(k));
expect(orphaned, `Orphaned keys in ${locale}: ${orphaned.join(', ')}`).toHaveLength(0);
}
});
});
```
### Step 5: Branch-Based Translation Workflow
Use Lokalise branching to isolate translation work per feature branch. This prevents in-progress translations from leaking into production:
```yaml
# .github/workflows/lokalise-branch.yml
name: Lokalise branch management
on:
pull_request:
types: [opened, synchronize, closed]
paths:
- 'src/locales/en.json'
jobs:
manage-branch:
runs-on: ubuntu-latest
env:
BRANCH_NAME: ${{ github.head_ref }}
steps:
- uses: actions/checkout@v4
- name: Create Lokalise branch on PR open
if: github.event.action == 'opened'
run: |
curl -X POST "https://api.lokalise.com/api2/projects/${{ secrets.LOKALISE_PROJECT_ID }}/branches" \
-H "X-Api-Token: ${{ secrets.LOKALISE_API_TOKEN }}" \
-HRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.