# Oversættelser

Blockstudio leveres med oversættelser i mappen `languages`. WordPress bruger dem, når webstedets sprog eller sproget i en brugerprofil matcher et af dem. Det fungerer på samme måde, når Blockstudio kører som et plugin, et must-use-plugin eller en Composer-pakke.

## Tilgængelige sprog

Blockstudio indeholder oversættelser til de WordPress sprogvarianter, der er registreret i dens medfølgende `languages/locales.json`, herunder regionale og formelle/uformelle varianter. Engelsk (`en_US`) er kildesproget og kræver ingen oversættelsesfil. Listen kombinerer WordPress-understøttede sprogvarianter fra GlotPress med varianter, der findes i WordPress-kernens oversættelses-API.

De eksisterende tyske (`de_DE`) og formelle tyske (`de_DE_formal`) oversættelser bevares. De yderligere oversættelser er AI-genereret med GPT-6 Luna og markeret som maskinoversatte i deres `.po`-headere. De består automatiske kontroller af fuldstændighed og format, men er ikke alle blevet gennemgået af modersmålstalere. Rettelser er velkomne.

Oversættelserne dækker feltkontrollerne i blokeditoren, administratorsiden, lærredet, devtools-overlayet og meddelelserne fra REST-endepunkterne. Etiketter og hjælpetekster i dine egne `block.json`-filer hører til dit tema eller plugin og bruger dets tekstdomæne.

Vælg sproget under **Indstillinger > Generelt > Webstedssprog**, eller vælg et personligt sprog i din WordPress-profil. Blockstudio bruger automatisk den pågældende sprogvariant. Det føjer ikke sprog til WordPress-sprogvalget: En sprogvariant skal også være tilgængelig i din WordPress-installation. Der kræves ingen AI-anmodning, oversættelsesabonnement eller ekstra runtimeindstilling på dit websted.

## Tilsidesæt en oversættelse

Oversættelsesfiler i `wp-content/languages/plugins` har forrang frem for de medfølgende filer, både for PHP-strengene (`blockstudio-de_DE.mo` eller `blockstudio-de_DE.l10n.php`) og for scripts (én fil pr. scripthandle, f.eks. `blockstudio-de_DE-blockstudio-blocks.json`).

## Bidrag med en oversættelse

Hvert sprog er en `.po`-fil, som du kan redigere med en hvilken som helst teksteditor eller et oversættelsesværktøj som Poedit. Rettelser og nye sprog er velkomne som pull requests.

1. Hvis du vil tilføje et sprog, skal du kopiere `languages/blockstudio.pot` til `languages/blockstudio-<locale>.po`, f.eks. `blockstudio-fr_FR.po`, og angive headerne `Language` og `Plural-Forms`. Hvis du vil forbedre et sprog, skal du redigere dets eksisterende `.po`-fil.
2. Oversæt strengene. Behold pladsholdere som `%1$s` i oversættelsen.
3. Kør `npm run i18n`. Den skriver filerne `.mo`, `.l10n.php` og `.json`, som WordPress indlæser.
4. Commit filen `.po` sammen med de genererede filer, og opret en pull request.

Hvis du ikke kan køre `npm`, er en pull request med kun filen `.po` helt fin. De genererede filer kan tilføjes før sammenfletningen.

## Generér manglende oversættelser

Vedligeholdere kan generere manglende poster med en godkendt Codex CLI. Dette er en valgfri udviklingskommando, ikke noget WordPress kører:

```bash
npm run i18n:translate -- --dry-run
npm run i18n:translate
```

Standardmodellen er `gpt-6-luna`. Brug `npm run i18n:translate -- --locale fr_FR` for at arbejde med én sprogvariant. Kommandoen udtrækker de seneste kildestrenge, udfylder manglende oversættelser og kompilerer derefter `.mo`-, `.l10n.php`- og `.json`-filer for hvert script. Kun offentlige grænsefladestrenge, deres kontekst og eksisterende former sendes til Codex, ikke webstedsindhold eller brugerdata.

Eksisterende oversættelser, der ikke er tomme, overskrives aldrig. Fuldførte batchjob gemmes, så en ny kørsel efter en afbrydelse fortsætter det manglende arbejde. Pladsholdere som `%1$s`, HTML-opmærkning, tekniske identifikatorer og de krævede flertalsformer valideres før lagring. Uafklarede poster og ændrede kildeflertalsformer overlades til en oversætter. Der bruges ingen alternativ model, hvis den ønskede model ikke er tilgængelig.

`npm run i18n:locales` opdaterer udtrykkeligt listen over sprogvarianter og flertalsregler fra WordPress/GlotPress. `npm run i18n:coverage` kontrollerer, at alle sprogvarianter på den indtjekkede liste er fuldstændige. Hverken dækningskontroller eller normal CI bruger AI eller henter sprogdata. Se arkivets README for muligheder for batchbehandling, samtidighed og gendannelse.

## Strenge, der kan oversættes i koden

- PHP: brug funktionerne WordPress med tekstdomænet `blockstudio`, for eksempel `__( 'Invalid block.', 'blockstudio' )`.
- JavaScript: importér `__` fra `@/utils/__`, og angiv en bogstavelig streng, for eksempel `__( 'Add row' )`. En streng, der sammensættes ved kørsel, kan ikke oversættes, så brug én bogstavelig streng pr. variant.
- En ny scriptpakke med strenge, der kan oversættes, skal have en post i `scripts/i18n.ts` og et kald til `wp_set_script_translations()` med samme handle og `Translations::script_path()`.

Når du har ændret strenge, skal du køre `npm run i18n`. Den opdaterer `languages/blockstudio.pot` og alle `.po`-filer. Nye strenge forbliver på engelsk, indtil en oversætter eller `npm run i18n:translate` udfylder dem. CI kører `npm run i18n:check` og `npm run i18n:coverage`, som afviser forældede kompilerede filer, problemer med udtrækning eller ufuldstændig dækning af lokaliteter. Generering er fortsat en eksplicit vedligeholderhandling.