typo3-translations
Guides TYPO3 13/14 localization with locallang.xlf, labels.xlf, XLIFF 1.2 and 2.0, ICU MessageFormat, LLL references, translation domains, Content Blocks labels, paths, namespaces, and migration checks. Use when the user mentions TYPO3 translations, localization, labels, XLIFF, ICU, LLL, missing keys, duplicate units, or v13-to-v14 translation migration.
What this skill does
# TYPO3 13/14 Translations
> Source: https://github.com/dirnbauer/webconsulting-skills
Use this skill for TYPO3 13 and TYPO3 14 translation files, XLIFF format
decisions, localization keys, ICU strings, `LLL:` references, and v14
translation-domain adoption. Start from the TYPO3 13-compatible baseline, then
apply TYPO3 14 upgrades when the extension or project is v14-only.
## Core Rules
- For TYPO3 13+14 compatibility, keep XLIFF 1.2 and full `LLL:EXT:`
references.
- For TYPO3 14-only work, prefer XLIFF 2.0 and consider translation domains in
PHP where they improve readability.
- Keep one source language file in English, unprefixed, for example
`Resources/Private/Language/locallang.xlf` or `labels.xlf`.
- Store target languages beside the source with locale prefixes, for example
`de.locallang.xlf`, `de_CH.locallang.xlf`, or `de.labels.xlf`.
- Do not create `en.locallang.xlf`; English is the unprefixed source.
- Keep exactly one `<file>` element per XLIFF file.
- Keep one target language per target file.
- Mark approved translations with `approved="yes"` in XLIFF 1.2 or
`state="reviewed"` / `state="final"` in XLIFF 2.0.
- Treat ICU MessageFormat as TYPO3 14.2+ only; do not use ICU for code that
must run unchanged on TYPO3 13.
- Use TYPO3 localization APIs and Fluid ViewHelpers; do not add custom label
loaders.
## Default Workflow
1. Inventory source files in `Resources/Private/Language/*.xlf` and
`ContentBlocks/**/language/*.xlf`.
2. Inventory consumers in PHP, TCA, YAML, Fluid, TypoScript, TSconfig, and
Content Blocks configuration.
3. Decide the compatibility mode:
- TYPO3 13+14: stay on XLIFF 1.2 and `LLL:EXT:`.
- TYPO3 14-only: migrate selected catalogs to XLIFF 2.0 and optionally use
domains/ICU.
4. Normalize paths, filenames, XML namespaces, and key namespaces.
5. Add or migrate labels with natural target-language copy.
6. Validate XML, duplicate IDs, source/target parity, and `LLL:` resolution.
7. Flush TYPO3 caches and smoke-test backend and frontend language contexts.
## TYPO3 13-Compatible Baseline
Use this baseline when an extension must support TYPO3 13 and 14.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" datatype="plaintext" original="EXT:my_extension/Resources/Private/Language/locallang.xlf" product-name="my_extension">
<header/>
<body>
<trans-unit id="button.save">
<source>Save</source>
</trans-unit>
<trans-unit id="items.count">
<source>Items: %d</source>
</trans-unit>
</body>
</file>
</xliff>
```
Target file:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" target-language="de" datatype="plaintext" original="EXT:my_extension/Resources/Private/Language/locallang.xlf" product-name="my_extension">
<header/>
<body>
<trans-unit id="button.save" approved="yes">
<source>Save</source>
<target>Speichern</target>
</trans-unit>
<trans-unit id="items.count" approved="yes">
<source>Items: %d</source>
<target>Eintraege: %d</target>
</trans-unit>
</body>
</file>
</xliff>
```
TYPO3 13 notes:
- Use `source-language="en"` and `target-language="<locale>"`.
- Use `<trans-unit>` inside `<body>`.
- Use `approved="yes"` for reviewed translations when approval state matters.
- Use `%s` / `%d` style placeholders and runtime formatting, not ICU.
- Use full `LLL:EXT:` references; translation domains are a TYPO3 14 feature.
## TYPO3 14 Changes
Use these changes when the project is TYPO3 14-only, or when preparing a v14
branch while keeping the v13 branch on the baseline above.
### XLIFF 2.0
Use this source shape for v14-only catalogs:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en">
<file id="messages">
<unit id="button.save">
<segment>
<source>Save</source>
</segment>
</unit>
<unit id="items.count">
<segment>
<source>{count, plural, one {# item} other {# items}}</source>
</segment>
</unit>
</file>
</xliff>
```
Use this target shape:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en" trgLang="de">
<file id="messages">
<unit id="button.save">
<segment state="final">
<source>Save</source>
<target>Speichern</target>
</segment>
</unit>
<unit id="items.count">
<segment state="final">
<source>{count, plural, one {# item} other {# items}}</source>
<target>{count, plural, one {# Eintrag} other {# Eintraege}}</target>
</segment>
</unit>
</file>
</xliff>
```
## Migrating XLIFF 1.2 To 2.0
Use this checklist only after the affected label family no longer needs TYPO3
13 compatibility:
1. Confirm `composer.json` and `ext_emconf.php` no longer support TYPO3 13.
2. Create a branch and convert one label family first.
3. Change `<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">`
to `<xliff version="2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en">`.
4. Remove the XLIFF 1.2 `<header>` and `<body>` wrapper.
5. Convert each `<trans-unit id="key">` to `<unit id="key"><segment>...`.
6. Move `<source>` and `<target>` inside `<segment>`.
7. Convert source-language/target-language attributes to `srcLang`/`trgLang`.
8. Convert `approved="yes"` to `state="reviewed"` or `state="final"`.
9. Split files that contain more than one `<file>` or more than one target
language.
10. Preserve unit IDs exactly; change references only when deliberately
renaming keys.
11. Validate XML and compare unit IDs between source and every target file.
12. Flush TYPO3 caches and verify labels in all affected backend/frontend views.
Do not migrate to a newer XLIFF dialect just because tooling can emit it. For a
TYPO3 14-only branch, use the documented XLIFF 2.0 shape unless the project has
verified support for another 2.x variant.
## ICU MessageFormat
TYPO3 14.2+ supports ICU MessageFormat when translation calls pass named
arguments. Store ICU strings as normal XLIFF `source` and `target` text.
For TYPO3 13+14 compatibility, avoid ICU and keep classic placeholders. Add ICU
only in v14-only code paths or v14-only label files.
Rules:
- Use named placeholders such as `{count}` and `{name}`.
- Do not translate placeholder names.
- Include `other` in every `plural` and `select` expression.
- Test plural messages with `0`, `1`, and multiple values.
- Use `LanguageService::translate()`, `LocalizationUtility::translate()`, or
Fluid `<f:translate arguments="{...}">`; `sL()` resolves plain labels only.
PHP:
```php
$label = $languageService->translate(
'items.count',
'my_extension.messages',
['count' => 5],
);
```
Fluid:
```html
<f:translate key="items.count" arguments="{count: itemCount}" />
```
## Paths, Namespaces, And Domains
Use stable file paths and key namespaces so references remain readable during
v13-to-v14 upgrades.
### File Paths
- Shared extension labels:
`EXT:my_extension/Resources/Private/Language/messages.xlf`
- Traditional extension labels:
`EXT:my_extension/Resources/Private/Language/locallang.xlf`
- Database/TCA labels:
`EXT:my_extension/Resources/Private/Language/locallang_db.xlf`
- Content Blocks labels:
`ContentBlocks/<Type>/<name>/language/labels.xlf`
Use full `LLL:EXT:` references where configuration is loaded outside an
Extbase context:
```php
'label' => 'LLL:EXT:my_extension/Resources/Private/Language/locallang_db.xlf:tx_my_table.title',
```
### XML Namespace
Use the XLIFF 2.0 namespace exactly:
```xml
xmlns="urn:oasis:names:tc:xliff:document:2.0"
```
### XLIFF IDs Versus TYPO3 14 Domains
Keep the XLIFF unit ID independent from the file/domain reference:
- XLIFF unRelated in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.